Re: [OAUTH-WG] OAuth Digest, Vol 72, Issue 31

[GHOST SPY <[e-mail]>]

[e-mail]
On Oct 16, 2014 4:21 AM, <[e-mail]> wrote:

> Send OAuth mailing list submissions to
>         [e-mail]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
>
>
> Today's Topics:
>
>    1. Re: Pete Resnick's No Objection on
>       draft-ietf-oauth-assertions-17: (with COMMENT) (Brian Campbell)
>    2. Re: Pete Resnick's No Objection on
>       draft-ietf-oauth-assertions-17: (with COMMENT) (Pete Resnick)
>    3. Richard Barnes' Discuss on draft-ietf-oauth-assertions-17:
>       (with DISCUSS and COMMENT) (Richard Barnes)
>    4. Richard Barnes' Discuss on draft-ietf-oauth-saml2-bearer-21:
>       (with DISCUSS) (Richard Barnes)
>    5. Richard Barnes' Discuss on draft-ietf-oauth-jwt-bearer-10:
>       (with DISCUSS and COMMENT) (Richard Barnes)
>    6. Stephen Farrell's No Objection on
>       draft-ietf-oauth-saml2-bearer-21: (with COMMENT) (Stephen Farrell)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 15 Oct 2014 17:35:19 -0600
> From: Brian Campbell <[e-mail]>
> To: Barry Leiba <[e-mail]>
> Cc: "[e-mail]"
>         <[e-mail]>, Pete Resnick
>         <[e-mail]>, oauth <[e-mail]>,
>         "[e-mail]" <[e-mail]>, The
> IESG
>         <[e-mail]>
> Subject: Re: [OAUTH-WG] Pete Resnick's No Objection on
>         draft-ietf-oauth-assertions-17: (with COMMENT)
> Message-ID:
>         <
> [e-mail]>
> Content-Type: text/plain; charset="utf-8"
>
> Fair point. I'll add some text saying that in the next revision.
>
> On Wed, Oct 15, 2014 at 5:18 PM, Barry Leiba <[e-mail]>
> wrote:
>
> >
> >>>    Assertions used in the protocol exchanges defined by this
> >>>    specification MUST always be protected against tampering using a
> >>>    digital signature or a keyed message digest applied by the issuer.
> >>>
> >>> Why is that? Aren't you using assertions over a protected channel (as
> >>> required by the spec) and therefore not need to sign the assertions?
> >>> Indeed, why would a self-issued Bearer Assertion need to be signed at
> >>> all? Does that even make sense?
> >>>
> >>>
> >> Yes, assertions are sent over a protected channel, which does provide
> >> integrity protection for the transport form client to AS and also gives
> >> server authentication. But it doesn't provide client authentication,
> which
> >> is kind of the point of the Client Authentication part of this draft.
> And
> >> for authorization the signing or MACing is what authenticates the
> issuer of
> >> the assertion - sometimes the issuer is the client but often the issuer
> >> will be a 3rd party system.
> >>
> >> I do agree with you in one specific case that, if the client is trusted
> >> to be the assertion issuer and the client is properly authenticated,
> then
> >> an unsigned assertion could be reasonably used as an authorization
> grant.
> >> But it's a fairly rare and very specific case. And one that can be
> >> accommodated in other ways. So it's not worth introducing the complexity
> >> and potential security problems that having the signature be option
> would
> >> bring.
> >>
> >
> > In other words, the assertion must be protected against tampering *by the
> > party that presents the assertion*.  That is a significant point, and you
> > should say it.
> >
> > Barry
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.ietf.org/mail-archive/web/oauth/attachments/20141015/27bf1330/attachment.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Wed, 15 Oct 2014 21:30:26 -0500
> From: Pete Resnick <[e-mail]>
> To: Brian Campbell <[e-mail]>
> Cc: "[e-mail]"
>         <[e-mail]>,
>         "[e-mail]" <[e-mail]>, The
> IESG
>         <[e-mail]>, oauth <[e-mail]>
> Subject: Re: [OAUTH-WG] Pete Resnick's No Objection on
>         draft-ietf-oauth-assertions-17: (with COMMENT)
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> On 10/15/14 6:06 PM, Brian Campbell wrote:
> > Thanks for your review and feedback, Pete. Replies are inline below...
>
> Thanks for addressing the comments, including Barry's followup. Just on
> the questions:
>
> > On Tue, Oct 14, 2014 at 2:42 PM, Pete Resnick
> > <[e-mail] <mailto:[e-mail]>> wrote:
> >
> >         scope
> >         [...]
> >                                                        As such, the
> >           requested scope MUST be equal or lesser than the scope
> >     originally
> >           granted to the authorized accessor.
> >
> >     s/MUST/will (unless you explain whether it's the server or the client
> >     that's supposed to be obeying that MUST, and for what reason)
> >
> >
> > They are both supposed to obey it - the client shouldn't ask for more
> > and the server will reject the request, if it does.
> >
> > Is "will" more appropriate than "MUST" here? Or maybe a non 2119
> "should"?
>
> Ah, so you're saying that a client could conceivably (either purposely
> or accidentally) try to sneak through a larger scope than it should, and
> the client MUST NOT do that, and the server MUST reject if it gets one.
> OK, that makes sense. (I do tend to like active MUSTs -- the foo MUST do
> X or the bar MUST NOT do Y -- but this is probably OK as is.)
>
> >     Here and throughout: s/non-normative example/example (As far as I
> >     know,
> >     there are no other kinds in IETF documents.)
> >
> >
> > I thought I picked that language up from some other draft or RFC but
> > I'm now not sure where it came from and can't easily find other
> > examples of the same thing.  So I am happy to remove the
> > "non-normative" throughout, if it is already understood and/or not
> > customary to say so.
>
> Yeah, we've seen other RFCs with such language. I've whined about it in
> the past. Some authors roll their eyes at me. You are welcome to roll
> your eyes if you like, but I find such text silly. :-)
>
> Thanks for the rest of the planned changes. Looks good.
>
> pr
>
> --
> Pete Resnick<http://www.qualcomm.com/~presnick/>
> Qualcomm Technologies, Inc. - [phone]
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.ietf.org/mail-archive/web/oauth/attachments/20141015/d746e674/attachment.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Wed, 15 Oct 2014 20:47:35 -0700
> From: "Richard Barnes" <[e-mail]>
> To: The IESG <[e-mail]>
> Cc: [e-mail],
>         [e-mail], [e-mail]
> Subject: [OAUTH-WG] Richard Barnes' Discuss on
>         draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="utf-8"
>
> Richard Barnes has entered the following ballot position for
> draft-ietf-oauth-assertions-17: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> "The assertion MUST contain an Audience that identifies the Authorization
> Server as the intended audience.  Assertions that do not identify the
> Authorization Server as an intended audience MUST be rejected."
>
> Could you please identify the threat model within which this "MUST" is
> required?  This requirement doesn't follow from any of the threats
> elaborated in Section 8.
>
> The Audience is only necessary if the Issuer wishes to constrain the set
> of Authorization Servers with which an assertion may be used.  So ISTM
> that this should be "MAY contain..."
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> "keyed message digest" -> "Message Authentication Code"
>
> That's the proper terminology [RFC4949], especially since there are MACs
> that are not based on digests.
>
> "This mechanism provides additional security properties." -- Please
> delete this or elaborate on what security properties it provides.
>
> Section 8.2 should note that "Holder-of-Key Assertions" are also a
> mitigation for this risk.
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 15 Oct 2014 20:56:40 -0700
> From: "Richard Barnes" <[e-mail]>
> To: The IESG <[e-mail]>
> Cc: [e-mail],
>         [e-mail], [e-mail]
> Subject: [OAUTH-WG] Richard Barnes' Discuss on
>         draft-ietf-oauth-saml2-bearer-21: (with DISCUSS)
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="utf-8"
>
> Richard Barnes has entered the following ballot position for
> draft-ietf-oauth-saml2-bearer-21: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> As with draft-ietf-oauth-assertions, the requirement for an <Audience>
> element seems entirely unnecessary.  Holding this DISCUSS point pending
> that discussion and its reflection in this document.
>
> "Assertions that do not identify the Authorization Server as an intended
> audience MUST be rejected." -- What does it mean for an assertion to
> "identify the Authorization Server"?  Does the specified <Audience> need
> to match the entire URL of the relevant OAuth endpoint?  Just the origin?
>  Just the domain?  Does the URL need to be canonicalized?
>
>
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 15 Oct 2014 21:01:22 -0700
> From: "Richard Barnes" <[e-mail]>
> To: The IESG <[e-mail]>
> Cc: [e-mail],
>         [e-mail], [e-mail]
> Subject: [OAUTH-WG] Richard Barnes' Discuss on
>         draft-ietf-oauth-jwt-bearer-10: (with DISCUSS and COMMENT)
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="utf-8"
>
> Richard Barnes has entered the following ballot position for
> draft-ietf-oauth-jwt-bearer-10: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> As with draft-ietf-oauth-assertions, the requirement for an "aud" claim
> seems entirely unnecessary.  Holding this DISCUSS point pending that
> discussion
> and its reflection in this document.
>
> "Assertions that do not identify the Authorization Server as an intended
> audience MUST be rejected." -- What does it mean for an assertion to
> "identify
> the Authorization Server"?  Does the specified <Audience> need to match
> the
> entire URL of the relevant OAuth endpoint?  Just the origin?  Just the
> domain?
> Does the URL need to be canonicalized?
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> "keyed message digest" -> "MAC"
>
> Both this and the SAML document could save a lot of bits by just being
> subsections of the -assertions document.
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 16 Oct 2014 04:20:32 -0700
> From: "Stephen Farrell" <[e-mail]>
> To: The IESG <[e-mail]>
> Cc: [e-mail],
>         [e-mail], [e-mail]
> Subject: [OAUTH-WG] Stephen Farrell's No Objection on
>         draft-ietf-oauth-saml2-bearer-21: (with COMMENT)
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="utf-8"
>
> Stephen Farrell has entered the following ballot position for
> draft-ietf-oauth-saml2-bearer-21: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> - intro para2: might be nice (no more) to add some refs to
> other protocols that use SAML.
>
> - 2.2: What are "padding bits" in 4648? I don't recall such.
> (But may be misremembering.)
>
> - section 3, list item 2: This doesn't quite say that the
> token endpoint URL MUST (in the absence of another profile) be
> in an Audience element. Why not? The text seems to me to allow
> for the AS to map the token endpoint URL to any value in an
> Audience element that the AS finds ok. I suspect that might be
> unwise, but it at least needs to be clear. Is that the text
> being ambiguous or me being paranoid/wrong? Same point seems
> to apply elsewhere too:
>    = in item 3.A where it says "typically identifies" but
>    does not say how.
>    = in item 5 "or an acceptable alias"
>
> - section 3, item 7: How might an AS know that "the Assertion
> was issued with the intention that the client act autonomously
> on behalf of the subject"?
>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ------------------------------
>
> End of OAuth Digest, Vol 72, Issue 31
> *************************************
>