Agreed & good point. I did think about it implicitly, but didn't address explicitly.
We should assume that intermediaries would add headers - but would neither add to the values of the set of headers we are interested in nor delete headers of interest to us. Is that a fair & deterministic assumption ? If so, we should specify the headers that should be signed. Again, in a binary mode - sign the specified headers or not sign any of them. Cheers <k/> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Brown Sent: Wednesday, December 10, 2008 3:42 PM To: [EMAIL PROTECTED] Cc: Louis Ryan; [email protected]; Scott Seely; Marc Worrell; [EMAIL PROTECTED] Subject: [opensocial-and-gadgets-spec] Re: body signing for oauth and opensocial On Wed, Dec 10, 2008 at 3:30 PM, Krishna Sankar (ksankar) <[EMAIL PROTECTED]> wrote: Brian, Now that we have beaten you to submission ;o), I think it becomes complex by requiring arbitrary named headers to be signed, with choice. Lot of thorny issues - How would an SP convey this ? What happens when this policy changes ? How would the error be sent back ? et al. Why can't we make it binary - just say header-signature-required or header-signature-not-required. And if required, sign all the headers or a set of well specified headers - no messy selection of which one to sign et al. You can't guarantee that the headers a container sends will be the only ones the remote site receives, for the same reason that you can't sign the final bytes transmitted and have to instead sign what you actually sent. BTW, we also need to include the additional parameters in the signature. (I am working on an end-to-end OAuth choreography for enterprises, for a few specific domains and require couple of domain-specific attributes to be passed around. So, my guess is that, the optional parameters would be very popular) Agreed on minimal normalization. I also want the HMAC-AES as one of the mechanisms, but haven't worked through the analysis of the bootstrap and the MEPs to make a definite pitch for that feature. Cheers <k/> |-----Original Message----- |From: [EMAIL PROTECTED] [mailto:opensocial- |[EMAIL PROTECTED] On Behalf Of Brian Eaton |Sent: Wednesday, December 10, 2008 8:23 AM |To: [EMAIL PROTECTED] |Cc: Louis Ryan; [email protected]; Scott Seely; Marc Worrell; |[EMAIL PROTECTED] |Subject: [opensocial-and-gadgets-spec] Re: body signing for oauth and |opensocial | | |(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 -~----------~----~----~----~------~----~------~--~---
