Umm, needless to say, I disagree with Roy on this one. =) To respond to the main point:
> And a security hole that you can drive a truck through. If you > are going to sign the routing bits, then you have to verify that > the route is the same in both the blob and the message so that > the blob is not being used to bypass route security (e.g., firewalls) > to access internal paths. Yes, the server needs to check that the URL it received and the URL that was signed match. This kind of check is extremely common in authentication protocols. It happens in SAML, OpenID, etc... Servers in all of those protocols verify that the "audience" field in the signed message matches the expected audience. All of those protocols are insecure if this check is left out. NTLM leaves this check-out, and this vulnerability can be used to launch relay attacks. OAuth 1.0 was unusual in that it required that the server match a hash of the URL, rather than the real URL. It's an extra layer of indirection and complexity. It doesn't improve security. Cheers, Brian On Thu, May 27, 2010 at 4:50 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > > > -----Original Message----- > From: Roy T. Fielding [mailto:field...@gbiv.com] > Sent: Thursday, May 27, 2010 4:48 PM > To: Eran Hammer-Lahav > Cc: HTTP Working Group (ietf-http...@w3.org) > Subject: Re: Duplicating request component in an HTTP authentication scheme > > On May 27, 2010, at 4:11 PM, Eran Hammer-Lahav wrote: > >> The OAuth working group is debating how to make signed authenticated >> requests. The two main questions is what do sign, and what to sign it with. >> On the 'what to sign part' we know we want to sign the request URI, HTTP >> method, and host name (among other cryptographic attributes such as >> timestamp and nonce). >> >> OAuth 1.0 includes a normalization process taking the request and >> serializing it into a base string (which is then signed). For OAuth 2.0, we >> have two competing proposals: >> >> 1. Normalize the request and send just the signature 2. Normalize the >> request and send both the signature and the signed string >> >> The advantage of #2 is that is moves the complexity from the client to the >> server. It is up to the server to figure out if the signed blob matches the >> request itself. The issue is that by doing so, the HTTP request is >> duplicated (HTTP request and authentication blob). Server will be required >> to compare the request with the blob to make sure they match. In practice, >> servers can ignore the request and just respond to the blob because it's the >> authenticated copy. >> >> The ramification of #2 is that it moves the HTTP request bits to another >> layer, creating a sort of wrapper. > > And a security hole that you can drive a truck through. If you are going to > sign the routing bits, then you have to verify that the route is the same in > both the blob and the message so that the blob is not being used to bypass > route security (e.g., firewalls) to access internal paths. > > If the server doesn't check the actual message, then don't bother to sign > anything. In other words, I say #1, or at least I would if this were not > heading down the exact same road as S-HTTP. > >> However, this approach should make it easier for client developers (who >> proved themselves to be extremely incompetent with the 1.0 specification) to >> get signatures right. It also allows for signing arbitrary data in addition >> to the HTTP request. >> >> Thoughts? > > The same client developers will have the same competence issues with regard > to any new spec. Just make sure that the protocol breaks visibly if anything > is done wrong, and then they can fix their own protocol stacks if they want > to implement this signing. > > ....Roy > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
