I think header signing and body signing can be done orthogonally. Krishna, you mentioned you had solid use cases for this, so perhaps you should propose a spec?
On Wed, Dec 10, 2008 at 5:13 PM, Krishna Sankar (ksankar) <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
