|
Hi Bernard, 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. 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. 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