Dick Hardt <[EMAIL PROTECTED]> writes: > On 19-Jun-06, at 2:59 PM, Eric Rescorla wrote: > >> CARRIED NONCRYPTOGRAPHICALLY INSIDE HTTP >> One approach that comes up quite a bit is to just embed >> authentication tokens (typically generated by an IdP) in >> the HTTP messages that go from the user to the RP (DIX is >> an example of such a scheme). In this system, the tokens >> themselves are "bearer"--they enable any holder to impersonate >> the user. In order to protect against token capture, the tokens >> are generally made specific to the RP, so that one RP can't >> use them to impersonate the user to another. >> >> 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] >> >> The primary attraction of this kind of design is that it >> may be implementable without changing the client software >> at all (again, see DIX). Many people see that as important >> for deployment. > > In DIX, the RP includes a nonce in the request, which must then also > be in the nonce which would prevent replay attacks assuming the RP is > managing nonce state would it not?
Only if each authentication token is only single-use. Otherwise, an attacker can replay it during the validity period. Even then, cut-and-paste attacks are still possible if you block the initial request. > I saw the security risk here being the reliance on DNS for identity > of the IdP in the verification step. Hmm.... I think this depends on the design. If you're using SSL/TLS, you should be able to block most attacks of this class, provided you have a CRA authentication method... -Ekr _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
