Sam Hartman <[EMAIL PROTECTED]> writes: > Hi. > > First, I'd like to thank you for this excellent starting point for the > discussion. I do have a few comments, but this is a great taxonomy.
Thanks. Sorry about the slow response here but I missed this message. > Requirements > > 2. Hijack-Resistant Authentication (HRA) > An authentication system in which credentials which are bound to > protocol messages in such a way that attacker who observes the > credentials can't use them to authenticate messages of their > choice. The rationale for this feature is to make cut-and-paste > attacks difficult. > > > I think this description and the subsequent discussion in > transporting/binding credentials has some concepts I'd like to > distinguish muddled together. > > Some schemes will provide integrity: a man in the middle can observe > the conversation but cannot modify the content of the request or > response. > > Some schemes will provide confidentiality even given the practical > difficulties with server certificate validation. Yes, I agree that these are separate services. I agree that confidentiality of information carried in the transaction important, but it's not in and of itself an *authentication* goal (though it may be used in the service of one if, for instance, the tokens used for authentication are bearer, like cookies.) > I argue in section 4.5 and 5 of version 01 of my phishing > requirements draft that providing confidentiality of the resulting > page is important even given these practical server certificate > issues. So, I'd like to ask you to add that as a potential > requirement I might want so I can ask for it. I'm not sure this is applicable, since I'm not really maintaining a document here. That was just a note to the list. > You don't seem to have a requirement that corresponds to section 4.6 > of 01 of my phishing requirements draft. This was one of the issues > muddled into the confusing mutual authentication section in 00 of my > draft. I contend that if there are a small number of RPs that by > policy should be allowed to accept a given identity,there is a > security benefit in restricting the identity to only those RPs. In > particular, if a user successfully authenticates the user knows that > because their identity was successfully accepted, they have > authenticated to one of the valid RPs. I'd be happy to discuss > specific customer deployments where this will be useful with you > off-list. I understand based on your review of my 00 draft that you > don't like this requirement. I still think it reasonable to discuss. I just forgot this one. My bad. That said, I think there are actually two security issues surrounding this: 1. Having the IdP perform some kind of secondary check on the identity of the RP. 2. Allowing the IdP to limit the use of credentials to selected RPs. These sound like the same thing but they're strictly speaking not. For example, consider a case where the IdP wants to charge RPs for access to their credentials. In order to do this, they encrypt the credentials with a fixed key that they send to subscribing RPs <insert suitable DRM, rollover, etc. here>. This doesn't provide any assurance to the user unless the RP demonstrates knowledge of the credentials. The RP might just choose to pretend it had authenticated the user, if, for instance, it wants to induce the user to give up personal information. > TLS Client AUthentication > > Your taxonomy assumes that TLS is a valid approach to client > authentication. I'm not making a judgement about whether it's valid or not. I'm saying it's been proposed. It has. > As I understand HTTP, that is only true assuming > there are no proxies between the user and the RP. no trusted proxies, technically speaking. TLS accelerators aren't a problem. I certainly have seen this issue raised, but I'd like to observe that they also exist for TLS without client auth (it's one reason why we designed S-HTTP the way we did) but people seem willing to live with that. > An additional issue is hijacking: without cryptographic > binding, an attacker who observes a request can make future > requests in the name of the user via a cut-and-paste attack > (remember, the token is bearer). If you take the threat of > this type of attack seriously, you need to run the traffic > over SSL/TLS. [1] > > > [1] Note that if you're worried about this class of attack, you need > *every* PDU to be cryptographically bound to the credential with > all designs. If, for instance, you use cert-based auth but then > transition to cookies over HTTP for state management, there's a > cut-and-paste attack there. > > > I think the primary paragraph is misleading. We've started from an > assumption that there are practical problems that prevent server > certificates from being validated. Given this assumption I don't > understand how TLS actually gives us protection against the > hijacking. Imagine a case where you have credentials that have CRA but not HRA. A good example is Boneh's PwdHash, which includes the domain name of the server in the "password". If it's restricted to use with SSL/TLS then you know that each RP will have a unique domain name and therefore each "password" is unique to a single RP, so there's automatic CRA--if the user is phished the phisher must pose as a different RP because he has a different certificate. [0] Note, however, that if you use TLS in NULL mode so that the password can be captured by a passive attacker, then he can issue a new request to the same server, thus mounting cut-and-paste attacks. This isn't strictly hijacking, nbut it's effectively the same for our purposes, since HTTP is connectionless. (I'm not sure I got the terminology on this feature exactly right). > I also think the footnote ignores an important deployment model. I > may be concerned about whether I have reached the right RP while not > concerned about network level hijacking. So I'm not at all convinced > that you always need to protect every exchange if you are concerned > about hijacking in some situations. By hijacking, I mean network level hijacking. If you mean typos and phishing, then I think this is a different threat. -Ekr [0] Remember that phishing's attack on cert validation is at the interface between the user's intention and the domain name, not at the interface between the certificate name and the domain name. _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
