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.
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
-~----------~----~----~----~------~----~------~--~---
