|
Hi Bernard, Reliance on discovery implies that there is no prior
relationship, but the document does not go so far as to explicitly make this
statement. Since this is so fundamental, a mention couldn’t hurt (to Section 3
perhaps). This protocol does not assume any prior relationship between access network and Device other than what is necessary for the Device to gain network access. However, I need to point out that there is a distinction between
network access authentication and the authentication that might be required for
access to the location service. If network access is granted, the LIS need not
add further hoops. Unless you can guarantee that all devices within the access network
are able to authenticate consistently, then you cannot authorize HELD requests
based on any authentication. There are networks where this is possible, but this
is a subset even of those “walled garden” networks. Therefore, the only form of authentication that a LIS is
permitted to use is the check that it performs to see whether the identifier it
is using as a basis for location determination belongs to the entity making the
request. Of course, local policy can override, as long as the implications are
considered (e.g. potentially denying emergency services access). --Martin p.s. I’m assuming that you meant 403 rather than 407 here. 407
implies that you are using a proxy. That tends to mess with the ability of the
LIS to see your IP address and it is expressly forbidden (c.f. Section 4.1.1).
From: Bernard Aboba
[mailto:bernard_aboba@xxxxxxxxxxx] Martin
Thomson said: "Regarding client authentication, there are a number of
constraints on the solution that lead to the current choice. The most
relevant constraint is that there may be no prior relationship between LIS
(network operator) and device. In designing for arbitrary access
networks, this constraint was considered important. This prevents use of
pre-shared keys such as would be required for digest/basic [1] [2]. Thus we come to the choice of IP address and return
reachability. I believe that the draft addresses the impact of this
choice adequately; Section 9.3 seems most directly applicable here, but other
places touch on this choice where it’s relevant. If you do not believe
that there are relevant points that are not brought up, I’d encourage you to
send text." [BA]
I understand that the IP address is being used as an identifier. With
respect to the lack of no prior relationship between the access network and the
device, presumably this is to acommodate situations of anonymous access and/or
no authentication (e.g. non-authenticated Ethernet). If so, it might be
useful to add a sentence to that effect. Regarding alternative identifiers, there is an extension
document that talks about use of alternative identifiers, and I do believe that
this particular point CAN be addressed in an extension. For those, authentication
(other than return reachability, if you consider that to be a form of
authentication) can be made a requirement. [BA]
I'm trying to understand how the mechanics of authentication could be
accomodated. Since authentication can't be required for authorization
where an IP address is used for identification, does this imply that a
"407" response is not permissible in that situation? Or is it
just saying that if a 407 is returned in that situation, then authorization
needs to be provided? Does that imply that a 407 could be returned in
other situations (e.g. an alternative identifier)? Just trying to
understand the scope of the prohibition and how implementations are expected to
behave. I’ll address the other more substantive point regarding identity
in PIDF-LO in another (longer) mail. --Martin [1] The document is clear on its use of digest/basic: the LIS
MUST NOT rely on it being used. That’s in recognition of the above
constraint. In other words, the LIS MUST NOT fail a request because the
device did not provide authentication. That doesn’t prevent it from being
used in an extension to the protocol. [2] Of course, there are networks where the constraint might not
be applicable. For instance, access to the network could be restricted
using some form of authentication. However, a device that accesses a LIS
within those networks must also be aware that it needs to present this same
authentication information when talking to a LIS. We cannot guarantee
that a device will do this, since compliance would need to be a prerequisite of
network access; designers of future access networks might choose to add this to
their network design. From: Bernard Aboba Mary
Barnes said: "It doesn't explicitly "forbid" the use of digest
authn, but if it can't depend on client support, then it can't really base any
decision on it." The question
isn't just about an authorization decision. There is also the issue about
what the
LIS is supposed to do with client authentication information if it is
provided. How is this
information reflected in the PIDF-LO that is returned in a HELD response? Ben
Campbell said:
|
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf