|
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