I find these arguments to be unpersuasive and somewhat offensive. There is no way for any machine to ever know where one ends and the other begins. Ergo it will be possible for someone to object to any protocol on the grounds that someone might conflate Authorization and Authentication. This is inevitable because there will be occasions where the intended authorization policy for a resource is to allow through everything that is authenticated.
________________________________ From: Stephen Kent [mailto:k...@bbn.com] Sent: Fri 2/20/2009 2:49 PM To: Hallam-Baker, Phillip Cc: ietf@ietf.org Subject: RE: Comments requested on recent appeal to the IESG At 9:00 PM -0800 2/19/09, Hallam-Baker, Phillip wrote: Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99318.3582B8D8" Just as a matter of observation, there is not and never has been a security requirement to rigidly separate authentication and authorization. Indeed there is no real world deployment in which authentication and authorization are not conflated to some degree. Authentication and authorization (aka access control) are distinct security services. Too often they are confused, and the result of such confusion is never a great outcome. I have not read the doc in question, but your dismissal of this issue is not persuasive. The separation of authentication and authorization is a matter of administrative and operational convenience. nonsense. the two are implemented via a wide range of mechanisms, many of which are independent of one another. I may use passwords or challenge-response mechanisms or PKI technology for authentication, and use various identity-based authorization mechanisms with any of these means of verifying an identity. Thus there are good technical and design reasons to consider the services and mechanisms separately, as part of a modular design approach. It is very rarely the case that every privilege that might potentially be granted to a user is known in advance. Hence the benefit of maintaining a distinction. But in practice the fact that a party holds a valid authentication credential is in itself often (but not always) sufficient to make an authorization decision in low-risk situations. True, but the fact that you had to employ several qualifiers in these sentences to make them true illustrates the benefits of distinguishing between the terms. Thus an objection based on the mere risk that such a conflation may occur is not justified as such conflation has occured in every practical security system ever. I don't know if the objection is an important one here, but I do think it is important in general. We do not issue employee authentication badges to non-employees. Thus an employee-authentication badge will inevitably carry de-facto authorization for any action that is permitted to every employee (like open the office door). A good example to make my point. It is typically the case that if all employees have ID badges, these badges grant access to most buildings/rooms of the employer's facilities. But many other rooms of an employer's facilities typically are off limits to all but a few employees. The Authorization/Authentication model is in fact broken, in a modern system such as SAML you actually have three classes of data with the introduction of attributes. SAML allows one to make security assertions of all sorts. The fact that one can make both authentication and authorization assertions using the same construct is distinct from the question of whether conflating the two terms is a good idea in general, as you seem to be arguing. Steve
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
