Brian,
Not yet. I need to do due diligence.
For now, two questions:
a) Header signing? Yes/No. I assume Yes - from your last
e-mail. If not we should continue that thread .
b) Assuming yes for #1 above, SP selects headers to sign.
Yes/No. I assume No and that the spec specifies a (fixed) list of
headers to sign.
If we agree to the above, we add header signature mechanisms to
the spec and the list of specific http headers we want to sign and the
mechanics for signing them.
If we do not agree to #1 and #2 above, we return to the feature
presentation and argue if headers need signatures.
Thoughts ?
Cheers
<k/>
P.S: Sorry for the paunchiness, am at the Big Nerd Ranch class in
Banning Mills - a little far away from civilization (like Starbucks) ;o)
Class is excellent, but one gets fried after the class !
|-----Original Message-----
|From: [email protected] [mailto:[email protected]] On Behalf
|Of Brian Eaton
|Sent: Wednesday, December 10, 2008 5:23 PM
|To: [email protected]
|Cc: Louis Ryan; [email protected]; Scott Seely; Marc Worrell;
|[email protected]
|Subject: [oauth] Re: [opensocial-and-gadgets-spec] Re: body signing for
|oauth and opensocial
|
|
|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
-~----------~----~----~----~------~----~------~--~---
