(Backpedaling on this, given that just about everybody who has chimed on this thread except me thinks signing headers is a good idea. =)
OK, how about this for a compromise on the question of signing headers: 1) Service providers may choose to require that certain headers be signed to guarantee their integrity. 2) If service providers require header signing, consumers will need to send a list of signed headers and their values to the server. 3) Some normalization of the headers will be required. I'd suggest something really minimal (as little interpretation of header values as is possible), but there are certainly other approaches. However, service providers won't need to accept the pain of header canonicalization and signing unless they also see a security benefit. For the majority of use cases where the headers are not security critical, interop will be easy. Sound reasonable? On Tue, Dec 9, 2008 at 11:54 AM, John Hayes <[EMAIL PROTECTED]> wrote: > Inline: > > On Tue, Dec 9, 2008 at 10:51 AM, Brian Eaton <[EMAIL PROTECTED]> wrote: >> >> [+marcw] >> >> Thanks for the feedback. >> >> On Tue, Dec 9, 2008 at 9:15 AM, John Hayes <[EMAIL PROTECTED]> >> wrote: >> > 1. Include HTTP entity headers: Content-Type, Content-Range, >> > Content-MD5, >> > Content-Language; they should be combined into a normalized base string, >> > URL >> > encoded to ascii and concatenated as a prefix with the body. The content >> > flags can affect how the entity is interpreted >> > 2. Exclude HTTP transfer encoding headers: Content-Length, TE, >> > Content-Encoding >> >> Marc Worrell made a similar suggestion. My initial proposal was not >> to bother with this, I would prefer not to include HTTP headers of any >> type in the signature base string, because I don't see how it fits >> into a realistic threat model. If an application is so sensitive that >> the possibility of changing a content-range header creates an >> unacceptable security risk, that application should probably be using >> https instead of OAuth over http. >> >> Is there a realistic threat here? > > > > Realistic? I guess it depends whether you think there's developer-processed > information in those fields. This seems more like an area that could exploit > bugs in the software through statistical variations rather than present a > systematic risk. > >> >> > 3. Specify exactly what will be hashed: I recommend after transforming >> > the >> > entity to bytes (no wide chars unless the endian is specified in the >> > charset), but before transfer encoding. >> >> Definitely not. The HTTP entity body (raw octets, as defined in >> section 7.2 of RFC 2616) should be hashed. No transformation should >> ever be done. This matches the definition of content-md5 in section >> 14.15 of RFC 2616. > > > > I suspect we're actually in agreement here, or maybe we have different ideas > about what is meant by "no transformation". There are three representations > for an HTTP entity: > > 1. The in-memory representation where data is system byte ordered, wide > chars, text mode > 2. The streamed representation, a byte-wise representation of the entity - > network byte order, multibyte chars > 3. The transfer representation, may contain a Content-Encoding (like gzip) > and a Transfer-Encoding that introduces intermediate byte marks. > > What RFC 2616 specifies is the third case: the MD5 is calculated after > compression and chunking (if any). What I think this standard should specify > is the second case, because applications rarely have access to a compressed > or chunked body even though APIs and plugins to transmit them are widely > available. Proxies may change Transfer-Encoding whever they feel it's > neccessary, which would break a hash in all of those cases - so the only > stable representation is the application's view. > > Another problem with RFC 2616 (call this 3a) is that it says the byte order > of the hash depends on the byte order in the content type (so uploading a > JPEG is big-endian while text is undefined). This standard should specify > little-endian. > >> >> > 4. Change parameter name to: oauth_entity_signature; slightly better >> > indicator that oauth_signature_method applies >> >> This is not a signature, since we are not using an HMAC. >> oauth_entity_hash would be fine by me. >> >> > 5. Specify that oauth_entity_signature MUST be included in the >> > oauth_signature base string if it's present in the request since this >> > differs from the treatment of oauth_signature. I see it in the example, >> > but >> > don't repeat the problems OAuth spec by putting critical information >> > only in >> > the examples or implementation. >> >> OK. >> >> > 6. State that signing a body is useless without a complete OAuth >> > authorization header that establishes the requester's identity. >> >> This seems kind of vague, how will it be helpful to people >> implementing the spec? If we're going to give security >> considerations, they should be actionable. > > > This really came out of the example where you demonstrated how an entity > hash would appear in a base string, however this example in practice isn't > useful because it's not actually signed with any OAuth fields. Maybe a > complete example would help. > >> >> > Normalizating HTTP headers is a lot trickier than query parameters >> > because >> > they may be rewritten by intermediate proxies and have multiple standard >> > forms with multi-line or single line representations, case insensitivity >> > and >> > optional quotes. >> >> I agree normalizing HTTP headers is tricky. Given that it provides >> negligible security benefit and is likely to cause interoperability >> problems, we shouldn't do it. > > > > The normalization isn't for the benefit of security it's for > interoperability. Normalization usually reduces security by creating > accidental iso-representations, but we can't reliably depend on every proxy > on the internet (and every web server API) providing an exactly byte-wise > representation of what was transmitted in headers. > > John > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
