Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187)

[Barry Leiba]

Further on this:

In the "editorial" realm, there are two classes of "correct" errata reports:

1. Trivial and obvious typos, such as spelling "and" as "adn".

2. Others, such as a number with transposed digits, which could,
indeed, be confusing.

The guideline that we're discussing is meant to separate those out,
saying that class 1 should go to HFDU, while class 2 might qualify as
Verified.  Whether a particular report falls into class 1 or 2 is
usually clear, but sometimes a matter of judgment.  And then whether a
class 2 report rates Verified or HFDU is also sometimes a matter of
judgment.  I'm personally happy with leaving that to judgment, rather
than trying to be overly rigorous about making rules for it.  I'm also
happy with the idea of clarifying or altering the guidelines, if
someone wants to make a specific proposal.

One thing we have talked about is having the RPC handle editorial
class 1 reports, and we can discuss that again if we like.  Should we
do that, it might make sense to have a separate handling code for
those that the RPC resolves.

Barry

On Mon, Jun 1, 2020 at 9:16 AM Barry Leiba  wrote:
>
> That's what the "technical" vs "editorial" distinction is supposed to be for.
>
> Barry
>
> On Mon, Jun 1, 2020 at 8:27 AM Rob Wilton (rwilton)
>  wrote:
> >
> >
> >
> > > -Original Message-
> > > From: iesg  On Behalf Of Benjamin Kaduk
> > > Sent: 31 May 2020 05:09
> > > To: Pete Resnick 
> > > Cc: m...@microsoft.com; i...@ietf.org; ve7...@ve7jtb.com;
> > > hannes.tschofe...@gmx.net; oauth@ietf.org; RFC Errata System  > > edi...@rfc-editor.org>
> > > Subject: Re: [Errata Verified] RFC7800 (6187)
> > >
> > > The new text is clearly the right thing, and there is no need
> > > to debate it if/when the document gets updated.  "Don't hold
> > > it; do it now", so to speak -- and noting that (my
> > > understanding/recollection of) the plan for
> > > https://www.rfc-editor.org/rfc/inline-errata/rfc7800.html is that only
> > > verified errata, not those in other states, will be displayed.
> > [RW]
> >
> > If this ends up being the plan, then I think that we may wish to modify the 
> > RFC guidance, or possibly have two different verified states:
> >  (i) Verified, could impact implementations
> >  (ii) Verified, editorial only.
> >
> > Certainly, it seems to be makes sense for these sorts of errata to be 
> > displayed.
> >
> > Regards,
> > Rob
> >
> >
> > >
> > > (Yes, that link 404s at the moment, I assume a caching issue.)
> > >
> > > -Ben
> > >
> > > On Sat, May 30, 2020 at 10:55:01PM -0500, Pete Resnick wrote:
> > > > "Verified", not "Hold For Document Update"?
> > > >
> > > > pr
> > > >
> > > > On 30 May 2020, at 20:34, RFC Errata System wrote:
> > > >
> > > > > The following errata report has been verified for RFC7800,
> > > > > "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)".
> > > > >
> > > > > --
> > > > > You may review the report below and at:
> > > > > https://www.rfc-editor.org/errata/eid6187
> > > > >
> > > > > --
> > > > > Status: Verified
> > > > > Type: Editorial
> > > > >
> > > > > Reported by: Pete Resnick 
> > > > > Date Reported: 2020-05-26
> > > > > Verified by: Benjamin Kaduk (IESG)
> > > > >
> > > > > Section: 7.1
> > > > >
> > > > > Original Text
> > > > > -
> > > > >[JWK]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
> > > > >   DOI 10.17487/RFC7157, May 2015,
> > > > >   <http://www.rfc-editor.org/info/rfc7517>.
> > > > >
> > > > >
> > > > > Corrected Text
> > > > > --
> > > > >[JWK]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
> > > > >   DOI 10.17487/RFC7517, May 2015,
> > > > >   <http://www.rfc-editor.org/info/rfc7517>.
> > > > >
> > > > >
> > > > > Notes
> > > > > -
> > > > > DOI has a typo: 7157 instead of 7517.
> > > > >
> > > > > --
> > > > > RFC7800 (draft-ietf-oauth-proof-of-possession-11)
> > > > > --
> > > > > Title   : Proof-of-Possession Key Semantics for JSON Web
> > > > > Tokens (JWTs)
> > > > > Publication Date: April 2016
> > > > > Author(s)   : M. Jones, J. Bradley, H. Tschofenig
> > > > > Category: PROPOSED STANDARD
> > > > > Source  : Web Authorization Protocol
> > > > > Area: Security
> > > > > Stream  : IETF
> > > > > Verifying Party : IESG
> > > >
> > > >
> > > > --
> > > > Pete Resnick https://www.episteme.net/
> > > > All connections to the world are tenuous at best
> >

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187)

[Barry Leiba]

That's what the "technical" vs "editorial" distinction is supposed to be for.

Barry

On Mon, Jun 1, 2020 at 8:27 AM Rob Wilton (rwilton)
 wrote:
>
>
>
> > -Original Message-
> > From: iesg  On Behalf Of Benjamin Kaduk
> > Sent: 31 May 2020 05:09
> > To: Pete Resnick 
> > Cc: m...@microsoft.com; i...@ietf.org; ve7...@ve7jtb.com;
> > hannes.tschofe...@gmx.net; oauth@ietf.org; RFC Errata System  > edi...@rfc-editor.org>
> > Subject: Re: [Errata Verified] RFC7800 (6187)
> >
> > The new text is clearly the right thing, and there is no need
> > to debate it if/when the document gets updated.  "Don't hold
> > it; do it now", so to speak -- and noting that (my
> > understanding/recollection of) the plan for
> > https://www.rfc-editor.org/rfc/inline-errata/rfc7800.html is that only
> > verified errata, not those in other states, will be displayed.
> [RW]
>
> If this ends up being the plan, then I think that we may wish to modify the 
> RFC guidance, or possibly have two different verified states:
>  (i) Verified, could impact implementations
>  (ii) Verified, editorial only.
>
> Certainly, it seems to be makes sense for these sorts of errata to be 
> displayed.
>
> Regards,
> Rob
>
>
> >
> > (Yes, that link 404s at the moment, I assume a caching issue.)
> >
> > -Ben
> >
> > On Sat, May 30, 2020 at 10:55:01PM -0500, Pete Resnick wrote:
> > > "Verified", not "Hold For Document Update"?
> > >
> > > pr
> > >
> > > On 30 May 2020, at 20:34, RFC Errata System wrote:
> > >
> > > > The following errata report has been verified for RFC7800,
> > > > "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)".
> > > >
> > > > --
> > > > You may review the report below and at:
> > > > https://www.rfc-editor.org/errata/eid6187
> > > >
> > > > --
> > > > Status: Verified
> > > > Type: Editorial
> > > >
> > > > Reported by: Pete Resnick 
> > > > Date Reported: 2020-05-26
> > > > Verified by: Benjamin Kaduk (IESG)
> > > >
> > > > Section: 7.1
> > > >
> > > > Original Text
> > > > -
> > > >[JWK]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
> > > >   DOI 10.17487/RFC7157, May 2015,
> > > >   .
> > > >
> > > >
> > > > Corrected Text
> > > > --
> > > >[JWK]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
> > > >   DOI 10.17487/RFC7517, May 2015,
> > > >   .
> > > >
> > > >
> > > > Notes
> > > > -
> > > > DOI has a typo: 7157 instead of 7517.
> > > >
> > > > --
> > > > RFC7800 (draft-ietf-oauth-proof-of-possession-11)
> > > > --
> > > > Title   : Proof-of-Possession Key Semantics for JSON Web
> > > > Tokens (JWTs)
> > > > Publication Date: April 2016
> > > > Author(s)   : M. Jones, J. Bradley, H. Tschofenig
> > > > Category: PROPOSED STANDARD
> > > > Source  : Web Authorization Protocol
> > > > Area: Security
> > > > Stream  : IETF
> > > > Verifying Party : IESG
> > >
> > >
> > > --
> > > Pete Resnick https://www.episteme.net/
> > > All connections to the world are tenuous at best
>

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Errata Verified] RFC7800 (6187)

[Barry Leiba]

> But https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/, 
> in particular:
>
> Only errors that could cause implementation or deployment problems or 
> significant confusion should be Verified.
> Things that are clearly wrong but could not cause an implementation or 
> deployment problem should be Hold for Document Update.
> Typographical errors which would not cause any confusions to implementation 
> or deployments should be Hold for Document Update.
>
> Did something change these criteria?

They're guidelines, not absolute rules, and judgment is expected.  I
support the guidelines, but I also appreciate and support Ben's good
judgment.  I, at least, am happy to leave it at that.

(That said, I did mark John Levine's errata report against RFC 20 as HFDU)

Barry

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)

[Barry Leiba]

> Yeah, with query parameters lacking the hierarchical semantics that the path 
> component has, it is much less clear. In fact, an earlier revision of the 
> draft forbid the query part as I was trying to avoid the ambiguity that it 
> brings. But there were enough folks with some use case for it that it made 
> its way back in. While I am sympathetic to the point you're making here, I'd 
> prefer to not codify the practice any further by way of example in the 
> document.

Is it perhaps reasonable to discourage the use of a query component
while still allowing it?  Maybe a "SHOULD NOT", such as this?:

OLD
  Its value MUST be an absolute URI, as specified by
  Section 4.3 of [RFC3986], which MAY include a query component but
  MUST NOT include a fragment component.
NEW
  Its value MUST be an absolute URI, as specified by
  Section 4.3 of [RFC3986].  The URI MUST NOT include
  a fragment component.  It SHOULD NOT include a query
  component, but it is recognized that there are cases that
  make a query component useful.
END

What do you think?

Barry

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)

[Barry Leiba]

>> AH.  I read later in the document and figured out my problem: I think it 
>> would
>> help if you hyphenate "audience-restrict" (and "audience-restricted" later).
>> No?
>
> Yes? Short of Adam Roach stepping in here to teach me more about proper use 
> of hyphens [1], I
> think that would be helpful and will make the changes.

:-)

This is a really tricky one, hyphenwise, and I'm not sure.  What I
*am* sure about is that if it were hyphenated I would not have had a
problem reading it.  Thanks for the quick response!

Barry

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)

[Barry Leiba via Datatracker]

Barry Leiba has entered the following ballot position for
draft-ietf-oauth-resource-indicators-05: 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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/



--
COMMENT:
--

-- Section 2 --

   invalid_target
  The requested resource is invalid, unknown, or malformed.

For clarity, I suggest adding "missing" to the list, as specified in Section
2.1, '...and MAY fail requests that omit the parameter with an "invalid_target"
error.'

   The authorization server SHOULD audience restrict issued access
   tokens to the resource(s) indicated by the "resource" parameter.

I can't parse this sentence.  I see "audience" as a verb, and don't understand.
AH.  I read later in the document and figured out my problem: I think it would
help if you hyphenate "audience-restrict" (and "audience-restricted" later). 
No?


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT)

[Barry Leiba via Datatracker]

Barry Leiba has entered the following ballot position for
draft-ietf-oauth-token-exchange-18: 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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/



--
COMMENT:
--

I have comments below, a couple of which might have been DISCUSS except that
there have been enough eyes on this and enough DISCUSSes already, and I trust
the authors and responsible AD to do the right thing.  So I’ve divided the
comments between “higher importance” and “purely editorial”.

Of higher importance:

— Section 1.1 —
Given the extensive discussion of impersonation here, what strikes me as
missing is pointing out that impersonation here is still controlled, that “A is
B” but only to the extent that’s allowed by the token.  First, it might be
limited by number of instances (one transaction only), by time of day (only for
10 minutes), and by scope (in regard to B’s address book, but not B’s email). 
Second, there is accountability: audit information still shows that the token
authorized acting as B.  Is that not worth clarifying?

— Section 8.2 —
RFC 8174 needs to be normative, along with 2119.

— Section 2.2.2 —

   If the authorization server is unwilling or unable to issue a token
   for all the target services indicated by the "resource" or "audience"
   parameters, the "invalid_target" error code SHOULD be used in the
   error response.

I always trip when I read “all” in a context like this.  I think you mean
“any”, because you have “a token”.  You could arguably make it “tokens” and
leave “all”, but I think changing to “any” is clearer:

NEW
   If the authorization server is unwilling or unable to issue a token
   for any target service indicated by the "resource" or "audience"
   parameters, the "invalid_target" error code SHOULD be used in the
   error response and no tokens are returned.
END

The danger with “all” is having a reader interpret the error as only occurring
when the server fails *all* services, and thinking that failing one out of
three still constitutes success.  I have seen this be an issue often (not with
OAuth, but in general).  If you want to be absolutely clear you could even add
to the end, “A request is successful only when all requested tokens are issued.”

— Section 5 —

   In addition, both delegation and impersonation introduce unique
   security issues.  Any time one principal is delegated the rights of
   another principal, the potential for abuse is a concern.  The use of
   the "scope" claim is suggested to mitigate potential for such abuse,
   as it restricts the contexts in which the delegated rights can be
   exercised.

I’m ambivalent here: is it worth also mentioning limiting the time a token is
valid and possibly make it a one-time-use token?  Or is it that that’s
adequately covered in the other references and shouldn’t be repeated here?

Also, is it worth referring (not copying) here to the advice in section 2.1
about the importance of authentication?

— Section 6 —
Should “TLS” here have a citation and normative reference?

=

Purely editorial:

— Section 1 —

   An OAuth resource server, for example, might assume
   the role of the client during token exchange in order to trade an
   access token, which it received in a protected resource request, for
   a new token that is appropriate to include in a call to a backend
   service.

A suggestion: I think this would work better using a restrictive clause, rather
than a non-restrictive one.

NEW
   An OAuth resource server, for example, might assume
   the role of the client during token exchange in order to trade an
   access token that it received in a protected resource request for
   a new token that is appropriate to include in a call to a backend
   service.
END

   The scope of this specification is limited to the definition of a
   basic request and response protocol for an STS-style token exchange

There should be hyphens in “request-and-reaponse protocol” (compound modifier).

— Sections 4.1 and 4.4 —

Section 4.1 says this:
   Consequently, non-
   identity claims (e.g., "exp", "nbf", and "aud") are not meaningful
   when used within an "act" claim, and therefore must not be used.

Section 4.4 says this:
   Consequently,
   claims such as "exp", "nbf", and "aud" are not meaningful when used
   within a "may_act" claim, and therefore shoul

[OAUTH-WG] Barry Leiba's Yes on draft-ietf-oauth-jwt-bcp-06: (with COMMENT)

[Barry Leiba via Datatracker]

Barry Leiba has entered the following ballot position for
draft-ietf-oauth-jwt-bcp-06: Yes

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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/



--
COMMENT:
--

Nice work on this; thanks.

-- Section 1 --

   Readers are advised to seek out any errata or updates that apply to this
   document.

Excellent.  I note that this is a really nice opportunity to include, here, a
URI to a page in the working group wiki or github that you can now create and
that will be used to post updates (that might not qualify as errata) before
they're incorporated into published updates.

Other than that,  I just have some editorial comments:

-- Section 1.1 --

   -  Implementers of JWT libraries (and the JWS and JWE libraries used
  by them),

Nit: Does "them" refer to the implementers or the libraries?  Please re-phrase
to clarify.

-- Section 2.4 --

Nit: "and thus, the ciphertext, depends" should be "and, thus, the ciphertext
depend" (note moved comma and plural verb).

-- Section 2.6 --

Nit: "However older implementations" needs a comma: "However, older
implementations"

-- Section 2.7 --
I find the paragraph to be somewhat awkward, and suggest a slight rewording,
thus:

NEW
There are attacks in which one recipient will be given a JWT that was intended
for it, and will attempt to use it at a different recipient for which that JWT
was not intended.  For instance, if an OAuth 2.0 [RFC6749] access token is
legitimately presented to an OAuth 2.0 protected resource which it is intended,
that protected resource might then present that same access token to different
protected resource for which the access token is not intended, in an attempt to
gain access.  If such situations are not caught, this can result in the
attacker gaining access to resources that it is not entitled to access. END

As to the title of this section, this doesn't seem to be a "substitution".  I'm
not sure what to call it (maybe it's a form of replay attack, but maybe not
really), but "substitution" doesn't seem right.

-- Section 2.9 --

Nit: In "operations, e.g. database and LDAP searches," you need a comma after
"e.g."  Or, better still, just change "e.g." to "such as", and avoid the Latin.

-- Section 3.4 --

Nit: "(see e.g.  [Valenta], Sec. 7.1)" needs commas: "(see, e.g.,  [Valenta],
Sec. 7.1)"  And in the next sentence, because of the "or both!" at the end I
would remove the "Either" at the beginning.

-- Section 3.6 --

   It is RECOMMENDED to avoid any compression of data before encryption
   since such compression often reveals information about the plaintext.

The passive voice doesn't work in this construct; "it is recommended to avoid"
doesn't seem like proper English.  Also, it's not the compression that reveals
information, but the resultant compressed data, right?  How about this?:

NEW
   Compression of data SHOULD NOT be done before encryption, because
   such compressed data often reveals information about the plaintext.
END

-- Section 3.11 --

   Confusion of one kind of JWT for another can be prevented by having
   all the kinds of JWTs that could otherwise potentially be confused
   include an explicit JWT type value and include checking the type
   value in their validation rules.

I find the sentence awkward, and suggest a slight rewrite:

NEW
   Sometimes, one kind of JWT can be confused for another.  If a particular
   kind of JWT is subject to such confusion, that JWP can include an explicit
   JWT type value, and the validation rules can specify checking the type.
   This mechanism can prevent such confusion.
END


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-proof-of-possession-09: (with COMMENT)

[Barry Leiba]

> Thanks for your review.  Please see my responses inline below...

And thanks for your responses.  All OK, including the alternatives you
gave to my suggestions.  Thanks, as always, for addressing my
comments.

Barry

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-proof-of-possession-09: (with COMMENT)

[Barry Leiba]

Barry Leiba has entered the following ballot position for
draft-ietf-oauth-proof-of-possession-09: 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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/



--
COMMENT:
--

The Abstract and Introduction both say something like this:

   This specification defines how a JSON Web Token (JWT) [JWT] can
   declare that the presenter of the JWT possesses a key and that the
   recipient can cryptographically confirm that the presenter possesses
   that key.

The JWT doesn't declare that the presenter possesses the key; it declares
that the presenter *must* possess the key... yes?  Shouldn't this say
that?:

NEW
   This specification defines how a JSON Web Token (JWT) [JWT] can
   declare that the presenter of the JWT must possess a key and how
   the recipient can cryptographically confirm that the presenter
   possesses that key.
END

(Also notice change from "that" to "how".)

   This
   specification defines how to communicate key confirmation key
   information in JWTs.

"key confirmation key information" seems odd and hard to follow.  I think
"key information used in key confirmation" is a better way to say it. 
But perhaps the sentence as a whole could be better phrased.  Does
something like this work?:

NEW
   This specification defines how to imbed into the JWT the key
   information that is used in key confirmation.
END

-- Section 2 --
Minor, very unimportant point: There's no reason to put, for example,
"(JWT)", when the citation "[JWT]" immediately follows it.  I suggest
just using the citation to provide the abbreviation, and eliminating
"(JWT)", "(JWK)", and "(JWE)".  But very unimportant; do, or don't, and
no need to respond to this item.

-- Section 3 --

   The issuer of a JWT declares that the presenter possesses a
   particular key and that the recipient can cryptographically confirm
   proof-of-possession of the key by the presenter by including a "cnf"
   (confirmation) claim in the JWT whose value is a JSON object.

I was convinced that this wasn't right until I read it for about the
eighth time.  It sounds like the recipient includes the "cnf" claim in
the JWT, when it's actually the issuer.  That happens when long sentences
have too many qualifiers strung together.  How about this?:

NEW
   By including a "cnf" (confirmation) claim in a JWT, the issuer
   of the JWT declares that the presenter possesses a particular key,
   and that the recipient can cryptographically confirm that the
   presenter has proof-of-possession of that key.  The value in the
   cnf claim is a JSON object, and members in that object identify
   the proof-of-possession key.
END

-- Section 3.5 --

   The protocol used to acquire the resource MUST provide integrity
   protection; an HTTP GET request to retrieve the JWK Set MUST use
   Transport Layer Security (TLS) [RFC5246]; and the identity of the
   server MUST be validated, as per Section 6 of RFC 6125 [RFC6125].

Little editorial punctuational nonsense: I would make the first semicolon
a colon instead (or perhaps a period), and I would then make the second
semicolon a comma.

-- Section 4 --
In the last paragraph, can you provide a reference for "audience
restriction"?

-- Section 6 --
Can we get this fixed in all the OAuth and JOSE documents?  It's getting
old having to make the same comment for every document:  We should not be
trying to set up IANA processes in our IANA Considerations.  The fourth
and sixth paragraphs aren't appropriate here: IANA coordinates and tracks
registration requests, and all requests should go to IANA.  IANA will
contact the DEs, not the other way around.  The authors have seen this
comment from me before


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth implementation fail

[Barry Leiba]

 Now, as to the spec change is concerned, I agree with John that it is not
 required.

 However, a Best practice document would probably help the developers.

That's exactly what I had in mind -- no spec change, but something (or
some things) to help guide developers into do the right thing,
security-wise and user-experience-wise.

Thanks, everyone, for discussing this.

Barry

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-spop-14: (with COMMENT)

[Barry Leiba]

 In JWS we used ASCII(string) to indicate that the output is a sequence of
 octets, strings are not necessarily 8 characters bits and may have null
 termination etc.

 However as Brian states other changes may have removed the need for that.

 I admit saying where STRING is a sequence of zero or more ASCII
 characters.” looks a bit circular.   How about saying where STRING is a
 sequence of zero or more characters”

 The ABNF in Sec 4.1 should keep people from going too wrong on its own.

 I think it is OK the way it is, but am willing to change it if people feel
 strongly.

As I've said, that one is the least important of all my comments, and
you folks should do what you think best there.  If you prefer to leave
the ASCII(x) notation for consistency, clarity, or whatever else,
I'm not going to say any more about it.

And many thanks for dealing with the other changes I've suggested.

Barry

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-spop-14: (with COMMENT)

[Barry Leiba]

Barry Leiba has entered the following ballot position for
draft-ietf-oauth-spop-14: 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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/



--
COMMENT:
--

Version -14 resolves my DISCUSS (and also some of my non-blocking
comments).  Thanks very much for considering these and working with me on
them!

  =
My comment about the IANA Considerations remains.  While it's
non-blocking, I still hope you will accept the change I suggest:

-- Section 6.2 --
I have the same comment here as in the other OAuth document: please shift
the focus away from telling IANA how to handle tracking of the expert
review, and make the mailing list something that the designated expert(s)
keep track of.  Also, please give more instructions to the DEs about what
they should consider when they're evaluating a request (for example,
should they approve all requests, or are there criteria they should
apply?).

For the first, here's a text change that I suggest we move toward for
this sort of thing:

OLD
most of Section 6.2

NEW
   Additional code_challenge_method types for use with the authorization
   endpoint are registered using the Specification Required policy
   [RFC5226], which includes review of the request by one or more
   Designated Experts.  The DEs will ensure there is at least a two-week
   review of the request on the oauth-ext-rev...@ietf.org mailing list,
   and that any discussion on that list converges before they respond to
   the request.  To allow for the allocation of values prior to
   publication, the Designated Expert(s) may approve registration once
   they are satisfied that an acceptable specification will be
published.

   Discussion on the oauth-ext-rev...@ietf.org mailing list should use
   an appropriate subject, such as Request for PKCE
   code_challenge_method: example).

   The Designated Expert(s) should consider the discussion on the
   mailing list, as well as these other things when evaluating
   registration requests.  Denials should include an explanation
   and, if applicable, suggestions as to how to make the request
   successful.
END

  =
-- Section 7.2 --
I find the first first paragraph confusingly worded, and after discussion
with the author I suggest this:

NEW
Clients MUST NOT downgrade to plain after trying the S256 method.
Because servers are required to support S256, an error when S256 is
presented can only mean that the server does not support PKCE at all.
Otherwise, such an error could be indicative of a MITM attacker trying
a downgrade attack.
END

  =
Finally, there is this comment, which is not a big deal and you should
proceed as you think best:

-- Section 2 --
There is no real distinction between STRING and ASCII(STRING), because
STRING is already defined to be ASCII.  Using ASCII(xxx) only adds
clutter, and a suggest removing it.

So, for example, that would result in changes such as this:

OLD
BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) == code_challenge
NEW
BASE64URL-ENCODE(SHA256(code_verifier)) == code_challenge
END


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-introspection-10: (with COMMENT)

[Barry Leiba]

Barry Leiba has entered the following ballot position for
draft-ietf-oauth-introspection-10: 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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/



--
COMMENT:
--

Thanks for addressing my DISCUSS and most of my comments.  The important
comment that still remains is this:

-- Section 3.1 --
I'd REALLY like to see us stop trying to tell IANA how to handle review
by designated experts.  This should be re-cast as instructions to the DE
(to make sure that the mailing list is consulted), and IANA should be
left to handle the expert review with their existing process, which works
fine.

While we're at it, it would be nice to have some further instruction to
the DEs about what they should be looking at when deciding whether to
approve a request.  There's some very minimal instruction under name in
the template, but that's all.  Is there nothing more to say?

For the spop document, I suggested the text change below.  Something
similar for this document would be great:

For the spop document, not this one!:
OLD
most of Section 6.2

NEW
   Additional code_challenge_method types for use with the authorization
   endpoint are registered using the Specification Required policy
   [RFC5226], which includes review of the request by one or more
   Designated Experts.  The DEs will ensure there is at least a two-week
   review of the request on the oauth-ext-rev...@ietf.org mailing list,
   and that any discussion on that list converges before they respond to
   the request.  To allow for the allocation of values prior to
   publication, the Designated Expert(s) may approve registration once
   they are satisfied that an acceptable specification will be
published.

   Discussion on the oauth-ext-rev...@ietf.org mailing list should use
   an appropriate subject, such as Request for PKCE
   code_challenge_method: example).

   The Designated Expert(s) should consider the discussion on the
   mailing list, as well as these other things when evaluating
   registration requests.  Denials should include an explanation
   and, if applicable, suggestions as to how to make the request
   successful.
END


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-spop-12: (with DISCUSS and COMMENT)

[Barry Leiba]

Hi, Nat, and thanks for the reply.

 How does plain do anything at all to mitigate this attack?  Wouldn't
 anyone who could snag the grant also be able to snag the code verifier as
 well?  Why is plain even here?

 You have to understand that this spec deals with a scenario that the
 communication is conducted over two segments:
 (1)Unprotected: Within the machine through mechanisms like custom
 scheme.
 (2)Protected: Over the network, which is protected by TLS.

 The “snagging” happens over the segment (1). For example, an attacker can
 snag the grant over this segment.

 However, he cannot snag code verifier because it is sent over (2), which is
 TLS protected.

Well, the code verifier isn't sent at all, as I understand the
protocol.  It's the transformed version, the challenge, that's sent.
Am I right?

Now, you appear to be telling me that the challenge (and method) that
are sent in Section 4.3 and the Authorization Response that is sent in
Section 4.4 are sent in different ways (though you don't say that in
the document), and that the transmission in 4.4 is open to
interception, but the transmission in 4.3 is not.  Is that an accurate
summary?

If it is correct that the transmission that's described in 4.3 can
*never* be intercepted, then I'm a bit less worried about plain.

But given the simplicity of implementing S256:

1. If there's *any* possibility of interception in some scenarios, I
still strongly oppose having plain at all, because if it's there,
it's bound to be used when it shouldn't have been.

2. I don't buy the argument that it's OK to build a weaker protocol
because implementors think that weak is good enough.  I think we need
to use our best protocol design principles and make sure what we
publish as standard is what we think reflects the best protocol
design.

On to the less strenuous stuff...

 General:
 I would think that this mechanism should never be a substitute for using
 TLS, and that this document should be explicit about that, and should say
 that the proper mitigation for situations where TLS can be used... is to
 use TLS.  Is there a reason we should NOT say that?

 OAuth (RFC6749 and RFC6750) mandates the use of TLS over the network.
 PKCE inherits this property. We could mention it again here, but it is sort
 of already done by inheritance.

That's true.  I'll leave this to your judgment, and no need for
further discussion.  The reason I mentioned it was to make sure that
implementors don't think that this mechanism can be a substitute for
TLS.  But if you think the OAuth specs are already solid enough on the
TLS thing, I'm OK with that.

 Putting quotation marks around code_verifier and code_challenge in
 the formulas is confusing: it makes it look as if you're putting in those
 strings themselves, rather than the values of the variables.  It's
 probably unlikely that anyone would make that mistake, but I nevertheless
 suggest removing the quotation marks when you mean to refer to the
 values.

 That’s the peculiarity of the current XML2TXT converter.
 In XML, it is spanx style=verb to signify strings themselves rather than
 the values of the variables.
 It renders nicely on HTML format etc., but TXT seem to have this confusing
 property.
 Perhaps RFC Editor can deal with.

I don't understand that.  When you say, for example:

   code_verifier == code_challenge

and

   BASE64URL-ENCODE(SHA256(ASCII(code_verifier )))
  == code_challenge

...you are not referring to the strings, but to the values, so why are
you marking them up at all?  They should just be this way:

   code_verifier == code_challenge

and

   BASE64URL-ENCODE(SHA256(code_verifier))
  == code_challenge

(see below about the ASCII() thing), with no markup causing quotation marks.

Or maybe I misunderstand what you're saying.  And, no, I don't think
we can leave it to the RFC Editor, unless we're quite explicit (with a
note in the document) about telling them exactly what we want them to
do.

 -- Section 2 --
 I don't understand the distinction between STRING and ASCII(STRING).  Can
 you please explain it?

 It is a notation used by JSON Web Signature, etc.
 It is making sure not to conflate the sequence of characters with sequence
 of octets of characters.

You already define STRING as a sequence of ASCII characters (and you
have OCTETS for arbitrary non-character octets).  ASCII is already a
character encoding.  So there's no need to say that you have to take
characters that are represented in ASCII, and represent them in ASCII.
It's redundant, and it adds clutter.

Of course, it's also not wrong, so this is not a DISCUSS, and you can
do as you think best.  I just suggest removing the ASCII()
throughout, as it's totally unnecessary, and, as I say, it adds
clutter.  I'll note that your definition of ASCII(STRING) is quite
convoluted, and the reason it's convoluted is that you have to twist
yourself around a pole to make definition that says anything other
than ASCII(STRING) is just STRING.

[OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-spop-12: (with DISCUSS and COMMENT)

[Barry Leiba]

Barry Leiba has entered the following ballot position for
draft-ietf-oauth-spop-12: 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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/



--
DISCUSS:
--

After getting John's explanation of the background and details of the
attack (and the different communications paths involved, I still would
prefer that we build this protocol as a more robust one (with only S256
and not plain), but I understand the reasons to have it this way, and I
think it will be acceptable with some changes to the text to make the
situation clearer.

To that end, I suggest this:

In the introduction, I think the explanation of Figure 1 (the fourth
paragraph) should be changed to make it clear what communication paths
are used in each step, and where the vulnerable piece is.  Something like
this:

OLD
   In step (1) the native app
   running on the end device, such as a smart phone, issues an
   authorization request via the browser/operating system, which then
   gets forwarded to the OAuth 2.0 authorization server in step (2).
   The authorization server returns the authorization code in step (3).
   The malicious app is able to observe the authorization code in step
   (4) since it is registered to the custom URI scheme used by the
   legitimate app.  This allows the attacker to reguest and obtain an
   access token in step (5) and step (6), respectively.
NEW
   In step (1) the native app
   running on the end device, such as a smart phone, issues an
   authorization request via the browser/operating system.  The
   request includes a URI by which the response will be returned,
   and that uses a custom URI scheme.  Step (1) happens through a
   secure API that cannot be intercepted.  The request then gets
   forwarded to the OAuth 2.0 authorization server in step (2).
   Because OAuth requires the use of TLS, this communication is
   protected by TLS, and also cannot be intercepted. The
   authorization server returns the authorization code over the
   same TLS connection in step (3). In step (4), the Authorization
   Code is returned to the requester via the URI that was provided
   in step (1).
   
   A malicious app that has been designed to attack this native
   app has previously registered itself as a handler for the custom
   URI scheme, and is now able to observe the Authorization Code in
   step (4).  This allows the attacker to request and obtain an
   access token in steps (5) and (6).
END

That (or something like it) makes it clear that only one step is
vulnerable, and explicitly tells us that the other communication paths
are already protected.

In the list of pre-conditions, I suggest changing (1) to make another
application be a legitimate application that uses OAuth.

*** IMPORTANT *** I am still puzzled by this, in pre-condition (4), which
seems to contradict what John said and what I proposed above:

   4) The attacker (via the installed app) is able to observe responses
  from the authorization endpoint.  As a more sophisticated attack
  scenario the attacker is also able to observe requests (in
  addition to responses) to the authorization endpoint.

Can you please explain the more sophisticated attack, and how the
attacker can observe the request?  Because plain will NOT work in such
a situation.

I suggest changing the last paragraph in the Introduction like this:

OLD
   To mitigate this attack, this extension utilizes a dynamically
   created cryptographically random key called 'code verifier'.  A
   unique code verifier is created for every authorization request and
   its transformed value, called 'code challenge', is sent to the
   authorization server to obtain the authorization code.
NEW
   To mitigate this attack, this extension utilizes a dynamically
   created cryptographically random key called 'code verifier'.  A
   unique code verifier is created for every authorization request and
   its transformed value, called 'code challenge', is sent to the
   authorization server to obtain the authorization code.  This
   transmission is sent through a secure API, and cannot be
   intercepted.
END

I know it repeats what was said in the explanation above, but it's an
important enough point to merit repetition.

I suggest changing Section 4.4.1 like this (because of a misuse of MAY
that I missed before):

OLD
   If the client is capable of using S256, it MUST use S256, as
   S256 is Mandatory To Implement (MTI) on the server.  Clients MAY
   use plain only

Re: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-spop-12: (with DISCUSS and COMMENT)

[Barry Leiba]

Hi, Hannes, and thanks for clearing this bit up.

4) The attacker (via the installed app) is able to observe responses
   from the authorization endpoint.  As a more sophisticated attack
   scenario the attacker is also able to observe requests (in
   addition to responses) to the authorization endpoint.
..
 In this model the adversary will see response messages. However, it is
 possible for an attacker to also compromise the smart phone OS in such a
 way that he/she is also able to see the request as well as the
 responses. In such a more sophisticated attack the proposed mechanism
 does not help.

Ah, got it.  Then it would be good for (4) to say that, maybe just by
adding to the end, This mechanism does not protect again the more
sophisticated attack.  Sound OK?

Barry

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-spop-12: (with DISCUSS and COMMENT)

[Barry Leiba]

 Hi, Hannes, and thanks for clearing this bit up.

4) The attacker (via the installed app) is able to observe responses
   from the authorization endpoint.  As a more sophisticated attack
   scenario the attacker is also able to observe requests (in
   addition to responses) to the authorization endpoint.
 ..
 In this model the adversary will see response messages. However, it is
 possible for an attacker to also compromise the smart phone OS in such a
 way that he/she is also able to see the request as well as the
 responses. In such a more sophisticated attack the proposed mechanism
 does not help.

 Ah, got it.  Then it would be good for (4) to say that, maybe just by
 adding to the end, This mechanism does not protect again the more
 sophisticated attack.  Sound OK?

That should be against, of course, not again.  I hate tupos.

Barry

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-spop-12: (with DISCUSS and COMMENT)

[Barry Leiba]

 attack by having 
 plain that is not available to an attacker by removing PKCE entirely from the 
 request.

 Unfortunately this week is CIS for me and I am having a hard time keeping up 
 with email.

 Let me know what you think.

 I agree that we want to direct developers to S256 as the preference, but that 
 only works if we get AS to deploy it, and developers to use it.

 John B.




 On Jun 11, 2015, at 3:35 AM, Barry Leiba barryle...@computer.org wrote:

 Hi, Nat, and thanks for the reply.

 How does plain do anything at all to mitigate this attack?  Wouldn't
 anyone who could snag the grant also be able to snag the code verifier as
 well?  Why is plain even here?

 You have to understand that this spec deals with a scenario that the
 communication is conducted over two segments:
 (1)Unprotected: Within the machine through mechanisms like custom
 scheme.
 (2)Protected: Over the network, which is protected by TLS.

 The “snagging” happens over the segment (1). For example, an attacker can
 snag the grant over this segment.

 However, he cannot snag code verifier because it is sent over (2), which is
 TLS protected.

 Well, the code verifier isn't sent at all, as I understand the
 protocol.  It's the transformed version, the challenge, that's sent.
 Am I right?

 Now, you appear to be telling me that the challenge (and method) that
 are sent in Section 4.3 and the Authorization Response that is sent in
 Section 4.4 are sent in different ways (though you don't say that in
 the document), and that the transmission in 4.4 is open to
 interception, but the transmission in 4.3 is not.  Is that an accurate
 summary?

 If it is correct that the transmission that's described in 4.3 can
 *never* be intercepted, then I'm a bit less worried about plain.

 But given the simplicity of implementing S256:

 1. If there's *any* possibility of interception in some scenarios, I
 still strongly oppose having plain at all, because if it's there,
 it's bound to be used when it shouldn't have been.

 2. I don't buy the argument that it's OK to build a weaker protocol
 because implementors think that weak is good enough.  I think we need
 to use our best protocol design principles and make sure what we
 publish as standard is what we think reflects the best protocol
 design.

 On to the less strenuous stuff...

 General:
 I would think that this mechanism should never be a substitute for using
 TLS, and that this document should be explicit about that, and should say
 that the proper mitigation for situations where TLS can be used... is to
 use TLS.  Is there a reason we should NOT say that?

 OAuth (RFC6749 and RFC6750) mandates the use of TLS over the network.
 PKCE inherits this property. We could mention it again here, but it is sort
 of already done by inheritance.

 That's true.  I'll leave this to your judgment, and no need for
 further discussion.  The reason I mentioned it was to make sure that
 implementors don't think that this mechanism can be a substitute for
 TLS.  But if you think the OAuth specs are already solid enough on the
 TLS thing, I'm OK with that.

 Putting quotation marks around code_verifier and code_challenge in
 the formulas is confusing: it makes it look as if you're putting in those
 strings themselves, rather than the values of the variables.  It's
 probably unlikely that anyone would make that mistake, but I nevertheless
 suggest removing the quotation marks when you mean to refer to the
 values.

 That’s the peculiarity of the current XML2TXT converter.
 In XML, it is spanx style=verb to signify strings themselves rather than
 the values of the variables.
 It renders nicely on HTML format etc., but TXT seem to have this confusing
 property.
 Perhaps RFC Editor can deal with.

 I don't understand that.  When you say, for example:

   code_verifier == code_challenge

 and

   BASE64URL-ENCODE(SHA256(ASCII(code_verifier )))
  == code_challenge

 ...you are not referring to the strings, but to the values, so why are
 you marking them up at all?  They should just be this way:

   code_verifier == code_challenge

 and

   BASE64URL-ENCODE(SHA256(code_verifier))
  == code_challenge

 (see below about the ASCII() thing), with no markup causing quotation 
 marks.

 Or maybe I misunderstand what you're saying.  And, no, I don't think
 we can leave it to the RFC Editor, unless we're quite explicit (with a
 note in the document) about telling them exactly what we want them to
 do.

 -- Section 2 --
 I don't understand the distinction between STRING and ASCII(STRING).  Can
 you please explain it?

 It is a notation used by JSON Web Signature, etc.
 It is making sure not to conflate the sequence of characters with sequence
 of octets of characters.

 You already define STRING as a sequence of ASCII characters (and you
 have OCTETS for arbitrary non-character octets).  ASCII is already a
 character encoding.  So there's no need to say that you have to take
 characters that are represented

Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT)

[Barry Leiba]

 1. Why is GET an optimization?  It has privacy disadvantages, and I
 don't see any advantages.

 2. This tight coupling thing is something that I think weakens the
 interoperability of the OAuth protocol in general, and I've never
 liked it.  In this case, in particular, I don't see any advantage to
 it, and I don't understand why it's useful to have an option that only
 works if you have inside knowledge, for no benefit.

 Why is it ever good to have clients that only work with certain
 servers, when it's just as easy to make sure that all clients work
 with all servers?

 I can see your point here, and others have raised it as well. Part of
 the reason the GET option is there is that most (if not all) of the
 existing implementations of this protocol enable it anyway. Having
 thought about this a bit, I would be fine with simply saying that POST
 is required and remaining silent on other methods in the main section.
 We can keep the warnings against also allowing GET in the security
 considerations. Will that work?

That will be of great excellence all 'round.  Thanks!

Barry

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT)

[Barry Leiba]

Hi, Justin.  Thanks for the response and discussion.

 -- Section 2 --

The introspection endpoint MUST be protected by a transport-layer
security mechanism as described in Section 4.

 I know what it means for a communication path to be protected by TLS, but
 I don't know what it means for an endpoint to be.  Can you explain that?

 The gist is simple: It must be served over HTTPS, not HTTP.

Right; that's protecting the communication path.  So I suggest this
(and it's a minor point; I'm OK with no further discussion, whether
you agree with the change or not):

NEW
   The introspection communication path MUST be protected by a
   transport-layer security mechanism as described in Section 4.
END

 -- Section 2.1 --
 The server MUST support POST, and MAY support GET.  What's the value in
 that?  I don't see any way for a client (I mean HTTP client, not Oauth
 client, here) to know, so all clients will have to send POST to be sure
 it will work.  Are you really expecting to have clients that want to ask
 this, but that can't send POST?  Given that you call out privacy concerns
 with GET, I don't see why it's there at all.

 GET is a deployment optimization that some servers will offer, and the
 OAuth client will tell the HTTP client which verb to use. The OAuth client
 might know through configuration (assuming a tighter coupling than
 defined by the interoperable protocol)

Two things:

1. Why is GET an optimization?  It has privacy disadvantages, and I
don't see any advantages.

2. This tight coupling thing is something that I think weakens the
interoperability of the OAuth protocol in general, and I've never
liked it.  In this case, in particular, I don't see any advantage to
it, and I don't understand why it's useful to have an option that only
works if you have inside knowledge, for no benefit.

Why is it ever good to have clients that only work with certain
servers, when it's just as easy to make sure that all clients work
with all servers?

Barry

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-spop-12: (with DISCUSS and COMMENT)

[Barry Leiba]

Barry Leiba has entered the following ballot position for
draft-ietf-oauth-spop-12: 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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/



--
DISCUSS:
--

How does plain do anything at all to mitigate this attack?  Wouldn't
anyone who could snag the grant also be able to snag the code verifier as
well?  Why is plain even here?


--
COMMENT:
--

General:
I would think that this mechanism should never be a substitute for using
TLS, and that this document should be explicit about that, and should say
that the proper mitigation for situations where TLS can be used... is to
use TLS.  Is there a reason we should NOT say that?

Putting quotation marks around code_verifier and code_challenge in
the formulas is confusing: it makes it look as if you're putting in those
strings themselves, rather than the values of the variables.  It's
probably unlikely that anyone would make that mistake, but I nevertheless
suggest removing the quotation marks when you mean to refer to the
values.

-- Section 2 --
I don't understand the distinction between STRING and ASCII(STRING).  Can
you please explain it?

-- Section 4.3 --
If plain does stay, why on Earth is it the default?  Even if just for
form's sake, shouldn't S256 be the default?

-- Section 4.4 --
The word code is used for too many things, and Authorization Grant is
already the right name for what we're talking about here.  I suggest that
in both the section title and body you use that term, to make it clear
what you mean by the code.  Similarly, in Section 4.5 please say
code_verifier rather than secret.

-- Section 4.4.1 --
Please expand PKCE, which is, at the moment, only expanded in the
document title.

-- Section 5 --
The SHOULD in the first paragraph is wrong.  You already have a MAY
covering the general behavior.  You should just take out the SHOULD,
and just say that severs supporting backwards compatibility revert to the
normal OAuth protocol.

-- Section 6.2 --
I have the same comment here as in the other OAuth document: please shift
the focus away from telling IANA how to handle tracking of the expert
review, and make the mailing list something that the designated expert(s)
keep track of.  Also, please give more instructions to the DEs about what
they should consider when they're evaluating a request (for example,
should they approve all requests, or are there criteria they should
apply?).

For the first, here's a text change that I suggest we move toward for
this sort of thing:

OLD
most of Section 6.2

NEW
   Additional code_challenge_method types for use with the authorization
   endpoint are registered using the Specification Required policy
   [RFC5226], which includes review of the request by one or more
   Designated Experts.  The DEs will ensure there is at least a two-week
   review of the request on the oauth-ext-rev...@ietf.org mailing list,
   and that any discussion on that list converges before they respond to
   the request.  To allow for the allocation of values prior to
   publication, the Designated Expert(s) may approve registration once
   they are satisfied that an acceptable specification will be
published.

   Discussion on the oauth-ext-rev...@ietf.org mailing list should use
   an appropriate subject, such as Request for PKCE
   code_challenge_method: example).

   The Designated Expert(s) should consider the discussion on the
   mailing list, as well as these other things when evaluating
   registration requests.  Denials should include an explanation
   and, if applicable, suggestions as to how to make the request
   successful.
END

-- Section 7.2 --
Please rewrite the first paragraph.  Please do not leave it for the RFC
Editor, as they may inadvertently get it technically wrong when they try.


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT)

[Barry Leiba]

Barry Leiba has entered the following ballot position for
draft-ietf-oauth-introspection-09: 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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/



--
COMMENT:
--

All of the stuff below is fairly minor and isn't blocking... but I would
like to discuss with you any items that you disagree with, please.

-- Section 1 --

   This specification defines an interoperable web API

How is that different from, This specification defines an API?  I don't
know why a web API differs from any other kind of API, nor what makes an
API particularly interoperable.  That said, this document appears not to
be defining an API at all... it seems to be defining a protocol.  Why do
you think it's an API?

-- Section 2 --

   The introspection endpoint MUST be protected by a transport-layer
   security mechanism as described in Section 4.

I know what it means for a communication path to be protected by TLS, but
I don't know what it means for an endpoint to be.  Can you explain that?

-- Section 2.1 --
The server MUST support POST, and MAY support GET.  What's the value in
that?  I don't see any way for a client (I mean HTTP client, not Oauth
client, here) to know, so all clients will have to send POST to be sure
it will work.  Are you really expecting to have clients that want to ask
this, but that can't send POST?  Given that you call out privacy concerns
with GET, I don't see why it's there at all.

-- Section 2.2 --
The definition of scope is odd, because I think you mean that it's a
single JSON string, and that the content of the string is a
space-separated list of scope values... it's not actually multiple JSON
strings, right?

-- Section 3.1 --
I'd REALLY like to see us stop trying to tell IANA how to handle review
by designated experts.  This should be re-cast as instructions to the DE
(to make sure that the mailing list is consulted), and IANA should be
left to handle the expert review with their existing process, which works
fine.

While we're at it, it would be nice to have some further instruction to
the DEs about what they should be looking at when deciding whether to
approve a request.  There's some very minimal instruction under name in
the template, but that's all.  Is there nothing more to say?

-- References --
Because many of the items in the response are defined in RFC 7519, I
think that RFC should be a normative reference.


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT)

[Barry Leiba]

 -- Section 3.1 --
 I'd REALLY like to see us stop trying to tell IANA how to handle review
 by designated experts.  This should be re-cast as instructions to the DE
 (to make sure that the mailing list is consulted), and IANA should be
 left to handle the expert review with their existing process, which works
 fine.

 OAuth and JOSE have been using mailing lists where several DEs are on the
 list and others can join.  These lists are separate from the WG mailing
 list.  DEs are names with IANA, but the spec review happens on that list,
 which is open.  This practice pre-date me as an AD.  I don't see what's
 wrong with it as it separates out the requests from the WG mailing list, but
 is still open and transparent.  Changing it now would alter how this spec
 works and would make it different from the other OAuth specs, which could be
 confusing.

I'm not objecting to the mailing list.  I'm objecting to telling IANA
how to integrate the mailing list into its procedure, which is
different from what its procedure is.  IANA initiates expert review
when it receives a request, contacting the DE and tracking the
process.  This tells IANA to send people directly to the mailing list,
and only to deal with requests from the DE.

The fact that requests need to be discussed on the mailing list is
something that the DE should be dealing with as part of her review,
and that takes us out of the business of telling IANA how to initiate
and track expert review, and making Oauth reviews different from those
for other protocols.

Barry

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-assertions-17: (with COMMENT)

[Barry Leiba]

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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-assertions-17: (with COMMENT)

[Barry Leiba]

Barry Leiba has entered the following ballot position for
draft-ietf-oauth-assertions-17: 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-assertions/



--
COMMENT:
--

Pete did a nice job on the 2119 key words, so I have nothing to add
there.

-- Section 6.1 --

   The example in Section 4.2 that shows a client authenticating using
   an assertion during an Access Token Request.

Is that an extra word that should be removed?  (Also in Section 6.3.)


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)

[Barry Leiba]

 At Stephen Farrell's request, I'm responding with   line prefixes
 on previous thread content.

Yeh, Outlook (and certain other clients, such as Lotus Notes) are
particularly bad at cooperating with the Internet-style quoting, and
it can get to be quite a mess as people with all different kinds of
mail clients start intermixing responses.  Waddyagonnado.

Maybe we oughta make a standard..

 We can update the text to clarify that MIME type comparisons
 are an exception to the code unit by code unit comparison rule.
 The drafts will also be scrutinized for other possible occurrences
 of exceptions to the default string comparison instructions.  Finally,
 we can add language to 7.1 about unless otherwise noted for a
 particular kind of string so that it's clear that there are exceptions
 to the rule.

That should work, and I'll have a look at the final result.  I'll note
that Ted Lemon (I think it was he) suggested that the documents might
leave the comparison text as is, and instead modify each place where
case-insensitive comparisons are needed by requiring that those items
be normalized to lower case (upper case would, of course, work as
well).  You might consider that, because it gets you out of the
business of trying to specify how to do the comparisons.

At some point, you might have other normalization and canonicalization
issues, though I don't see any right now.  If, for example, you might
ever have a field value containing something like kühl, you'll have
to deal with two ways to represent the ü (as a single character, and
as two (a u plus a combining umlaut)).  It might be that that's
never going to be an issue for the JW* stuff.  But if it ever is (if
there are ever such strings that might be typed in by users), it could
be a problem.

Barry

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Draft Agenda

[Barry Leiba]

 Any idea, on the two Assertion Documents, if there is or will be any
 feedback from the IESG and, if so, what form it might take?

I'm sorry that I haven't been able to get to reviewing this yet --
I've had a bunch of pre-IETF travel, in addition to preparing for the
meeting.  I aim to have a look on the flights to London, so I hope to
get you feedback this Thursday.

Barry

 There's a
 chance #2 takes considerably less than 15 minutes, if there's no
 feedback. And hopefully 15 mins will be sufficient, if there is some
 feedback.

 On Mon, Feb 24, 2014 at 11:47 AM, Hannes Tschofenig
 hannes.tschofe...@gmx.net wrote:
 Hi all,

 we put a draft agenda online:
 http://www.ietf.org/proceedings/89/agenda/agenda-89-oauth

 Let us know whether this sounds reasonable for you.

 Ciao
 Hannes  Derek

 ___
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth


 ___
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Reaction to the current assertion pair {framework, SAML}

[Barry Leiba]

 Any idea, on the two Assertion Documents, if there is or will be any
 feedback from the IESG and, if so, what form it might take?

 I'm sorry that I haven't been able to get to reviewing this yet --
 I've had a bunch of pre-IETF travel, in addition to preparing for the
 meeting.  I aim to have a look on the flights to London, so I hope to
 get you feedback this Thursday.

It's not Thursday yet, at least not in San Diego, but I've had time in
the UA Club before flying out.  I haven't reviewed them in detail, but
I looked through them with respect to the DISCUSS issues I'd raised
before.

You'll be happy to hear that on those issues, I think we understand
each other and the current documents seem fine -- they define things
in a way that I think people can implement interoperably without
calling someone on the phone first.

Thanks for sticking with this, understanding what I was on about, and
sorting it out.

Barry

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Question/comments on draft-ietf-oauth-revocation-09

[Barry Leiba]

 Sergey has the correct interpretation -- it's to prevent a class of oracle 
 attacks.
 Think of it this way, if you go to revoke a token, and the token wasn't there 
 in the
 first place, the end result is the same: the token's not there when you're 
 done. So
 it's a 200 because the result is what you wanted even if the state going in 
 was wrong.

This highlights my point in my AD review:
https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/ballot/

...that this is *not* revocation.  It's invalidation or surrender
(requested by the bearer of the token) -- revocation would be an
action by another party to invalidate a token without the bearer's
involvement.

The usual defense against the sorts of attacks you're talking about is
to make the failure conditions indistinguishable -- not to make
success indistinguishable from failure.  That is, you have two
responses, success and failure, but the failure response doesn't say
why.

What, specifically, is the attack you're trying to defend against
here, any why is this the best approach to that attack?  I can't see
how a please invalidate this token request can in any way take
advantage of a no response to mount an attack.  It's possible that
there really is a threat here and that this is the right way to handle
it, but I'd like to see that explained.

Barry, Applications AD
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Question/comments on draft-ietf-oauth-revocation-09

[Barry Leiba]

 As I recall, the argument was that without this, someone could just keep 
 fishing at the
 token revocation endpoint for valid tokens. Though thinking about it now, 
 even if you
 did get a token was valid response, the token wouldn't be valid anymore and 
 it wouldn't
 do you much good.

Right, exactly.

 It's possible that invalidation is a better term for this, but is there an 
 established semantic
 precedent for this distinction?

In English, yes (I don't know about in Computer):

If I walk down to the motor vehicle office, hand them my driver's
license, and say, Here, take this and destroy it, please.  I don't
need it any more, then I will no longer have a valid driver's
license... but *no one* would say that my license had been revoked.

If I'm caught driving drunk one too many times, and a judge says,
Take the bus from now on, and orders my driver's license revoked,
that's a real English-language revocation.  Note the connotation
that it's imposed on me by another party, not done at my request.

This isn't a huge point, which is why I didn't mark it as a DISCUSS
point, and I won't block the document if it's not changed.  But I
think it *should* be changed, and might cause confusion if it's not,
especially if we ever do set up a true revocation protocol.

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10

[Barry Leiba]

 The eventbrite page for people wanting to attend the openID Connect session
 prior to IETF86 is now available at:
 http://openid-ietf-86.eventbrite.com/

That page says this:
   OpenID Meeting at IETF 86
   The OpenID Foundation
   Thursday, April 11, 2013 from 1:00 PM to 4:00 PM (EDT)
   Orlando, FL

I do hope it means Thursday, 7 March.  11 April is about a month
*after* the IETF meeting.

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Mandatory to implement

[Barry Leiba]

 I can tell you that I don't think Barry and I are asking for
 contradictory things. They are different, but not contradictory,
 and have the same goal (interop). I believe Barry would agree
 with that.

 Saying that field X is MTI can be entirely consistent with
 defining a protocol that allow for negotiating whether or
 not to use field X for example.

He would, indeed agree with that -- with all of it.

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] oauth assertions plan

[Barry Leiba]

I'll get to John's message later, after I digest it more.  I can reply to
this one now.

please explain how you and I can each write applications to that?

 **

 ** **

 You can write applications to that by having the profile chain end, and
 with the contents of the Audience field being completely specified
 somewhere in the profile chain being used.


In order for that to work, we have to know (we being both sides of the
protocol, and also we being different implementors of similar
applications) what profile to use.


 I am proposing that there must be a way for someone writing an application
 to know what to use in these fields that will work with your application
 (or will work with a server in the same way as your application does, or
 whatever) *without* having to go to the documentation of your application
 to figure it out.

 ** **

 I agree with what I think you mean, but possibly not with how you’re
 saying it.  Using the TCP analogy again, in fact, to understand the
 contents of the TCP stream for port 25, one has to go to the documentation
 of the application communicating on port 25.  In this case, that
 documentation is RFC 821 and its successors.

 Yeh, here's where we're disconnected.  One does NOT have to go to the
documentation of the application at all.  One has to go to the
specification of SMTP.  But one needn't know *anything* about any other
implementations of SMTP: everything you need is in the SMTP spec (including
that it runs on port 25).

If there were a similar thing here, I'd be happy.  But if there's a similar
thing here, I don't see it.

I’ll also observe that the working group is also working on a specification
 that enables an OAuth client to dynamically register itself with the
 Authorization Server (draft-ietf-oauth-dyn-reg) *and that that
 registration does declare information about what profile is being used*,
 as John Bradley pointed out in his response.  That’s a key piece of the
 whole solution to enable interoperable implementations.


It sounds like it is a key piece, and in that case I think that document
needs to come forward along with (or before) the ones that depend on it for
interoperability.  Absent something like that, we can't evaluate whether
it's possible to write interoperable implementations of this spec.

  We already do have mechanisms for dynamically declaring what profile is
 being used, and we are using them.


Dynamically declaring, in what sense?  Where are those mechanisms
documented?


 I agree with Stephen that we should let this conversation run for a while
 to make sure everyone comes to a common understanding, but ultimately, I
 hope that you’ll withdraw your DISCUSS, because, in fact, interoperable
 implementations can be written by reading the specs used alone.


I still don't see that that's true (how did those interoperable
implementations resolve the incompletely specified bits?), but, in any
case, don't obsess over the DISCUSS ballot, because it no longer matters:
Stephen has returned the document to the working group, and when it comes
back to IESG Evaluation again I'm sure Stephen will issue a new ballot and
we'll start the process from a clean slate.

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] oauth assertions plan

[Barry Leiba]

 It seems like the scope of your criticism has more to do with RFC 6749 
 RFC 6750 overall, than the assertions drafts themselves.


No, and I'm sorry if it came across that way.  I mentioned the token-type
issue only by way of background.  As it happens, I do think it was a
mistake to publish the oauth framework spec without a mechanism for
discovery/negotiation/communication of token types, but I'm not holding
that against this document at all.


 In OpenID Connect we implemented a discovery and registration layer for
 clients to discover what the Authorization server supports.


Great!  I think that each use of the protocol shouldn't have to roll this
on its own, but it's good that OIDC did it.


 To acceve real interoperability these things need to be profiled or you
 need a negotiation mechanism.


We do agree on that; cool.


 Are you saying that Assertions needs a low level mechanism to negotiate
 capabilities?
 Many will argue that specs at a higher level like like Dynamic Client
 Registration https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/are 
 better places to address these capability negotiations because as you
 point out there is more to be negotiated than just assertions.


I would be happy to have it done that way, but then I think that needs to
happen first, and this needs to refer to that (normatively) as the (or a)
mechanism that helps this interoperate.


 It has been stated by one of the WG chairs that some of us are anti
 interoperability, so some of us may be a touch sensitive, around this, as
 it is not the case.


Yeh, we very much need to keep that kind of rhetoric and questioning of
motives out of the discussion.  You won't hear it from me, certainly.
 Quite the opposite: I'm quite confident that we all share the goal of
developing good specs from which interoperable implementations can be
built.  It's not a question of anti-anything, but of disagreement about how
to accomplish that.

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] oauth assertions plan

[Barry Leiba]

 Dynamically declaring, in what sense?  Where are those mechanisms
 documented?

 ** **

 Many of them are documented in draft-ietf-oauth-dyn-reg.

 ** **

 One profile (an outer doll J) that enables fully interoperable
 implementations is documented in draft-hardjono-oauth-umacore.

 ...

 Another related profile that enables fully interoperable implementations
 is documented in http://openid.net/specs/openid-connect-messages-1_0.html.


It's possible, then, that this isn't an issue of major changes needed in
this document, but one of document ordering.  It's possible (I'm still not
sure, but maybe) that if some of these other documents came out before or
at the same time as this one, they would all fit together and all would be
clear.

So maybe that's one way through this.

In the end, all I'm saying is that if I hear that everyone is using oauth
to peel bananas, and I want put my banana-peeling application on the market
by adding oauth to it, I need to be able to read a set of specs that say
how to do that, and that's all.  And if I do that, my application will work
when it's slotted into any oauth-based banana-peeling system.

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] oauth assertions plan

[Barry Leiba]

OK, I have some time to respond to this on a real computer.

Let's look at the general mechanism that oauth provides, using one use case:
A client asks an authorization server for authorization to do something.
The authorization server responds with an authorization token, which
the client is required to understand.

We have talked about three kinds of tokens: bearer tokens, MAC tokens,
and assertion tokens.
How does a client know what kind of token it will get from a
particular authorization server?
How does a server that supports multiple token types know what kind of
token it should give to a particular client?

Now, suppose that the server decides to give back an assertion:
How does the server know whether to give a SAML assertion or a JWT
assertion?  How does the client know which it's going to get?

And now you're saying that even if everyone knows they're going to get
an assertion token, and specifically a JWT assertion, the semantics of
particular fields in those tokens are undefined.  If you have
different meanings (different kinds of things, as you've said) for
the Audience field, how is the server supposed to communicate which
meaning *it* is using?  How is there any assurance that a client will
understand it in the same way?

These are the sorts of things I'm concerned about, and this is what I
mean by saying that it's like a Ukrainian doll: you open the oauth
doll and find the token doll; you open the token doll and find the
assertions doll; you open the assertions doll and find the JWT doll;
you open the JWT doll and find the Audience field doll... at what
point do the dolls end and interoperablity begins?

I understand that you want certain things to be handled differently by
different applications, and I'm fine with that in principle.  But the
other part of the principle is that I have to be able to write an
application that interoperates with yours *purely by reading the
specs*.

If you do this by profiling, we need to get to a point where two
things are true: (1) the profile chain has ended, and what's left is
well defined, and (2) I have to be able to, *from the specs and the
protocol alone*, determine what profile will be used.  I don't see how
this protocol gives me any way to determine what to send or what to
expect to receive.  And if an out-of-band understanding is required
for that, that doesn't interoperate.

Now, the way we usually handle the need for different kinds of
things is to have different fields for each, or to have one field
tagged so that it's self-defining (as URIs have a scheme that says
what to do with them).  If the Audience field might look like this in
one application:
   urn:ietf:params:banana
...and like this in another
   abra:cadabra
...where the first is understood to be a URI and the second is
something else, then please explain how you and I can each write
applications to that?

For your specific questions:

 Barry, are you proposing that we require that the Audience contain a specific 
 data
 format tailored to a particular application of assertions?  If so, what 
 format are you
 proposing, and for which application of assertions?  Likewise, are you 
 proposing
 that the Subject field contain a particular data format tailored to a 
 particular
 application?  And also the Issuer field?

I am proposing that there must be a way for someone writing an
application to know what to use in these fields that will work with
your application (or will work with a server in the same way as your
application does, or whatever) *without* having to go to the
documentation of your application to figure it out.

That's why I say that as I see it, it's not an issue of MTI.  I'm not
saying that I want you to require that any particular thing be
implemented.  I'm saying that both sides need to be able to know which
variations *are* implemented.  How else do you get interoperability?

Your TCP/ports example is a perfect one to show how this works: the
assignments for port numbers are *exactly* to create the
interoperability I'm talking about here.  TCP doesn't say anything
about the protocol (profile, perhaps) that's used over it.  But
we've defined that port 110 is used for POP and 143 is used for IMAP
and 25 is used for SMTP, and so on.  So I know that if my IMAP
application wants to talk with your IMAP server, I can accomplish that
by using port 143.  If you decide to run your IMAP server on port 142
instead, or if you run your POP server on port 143, we will not
interoperate.

But all I need to know is (1) how to do IMAP, (2) how to do it over
TCP, and (3) what port to use... and I can build an IMAP client that
will work with any IMAP server that follows the same specs.

Can you do that here?  Please explain how.

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (3446)

[Barry Leiba]

 Corrected Text
 --
 Resource owners cannot revoke access to an individual third party without 
 revoking access
 to all third parties, and must do so by changing their password.

 Notes
 -
 The text was originally their but changed to the third party's between 
 the last draft and RFC.
 However, their means resource owners', not the third party's.

Yes, this appears to be a change the RFC Editor made that the authors
didn't notice in AUTH48.  But the RFC Editor change it from their
because their wasn't clear.  Changing it back to their won't help
that.  I suggest editing the corrected text to by changing the
resource owner's password before marking this as Verified.

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] fyi: IETF conflict review results for draft-secure-cookie-session-protocol

[Barry Leiba]

 [ I was nosing around and noticed this relatively recent decision, it didn't
 appear to have been fwd'd to these lists. fyi/fwiw... ]
...
 The IESG has no problem with the publication of 'SCS: Secure Cookie
 Sessions for HTTP' draft-secure-cookie-session-protocol-08.txt as an
 Informational RFC.

 The IESG has concluded that this work is related to IETF work done in the
 websec and httpbis working groups, but this relationship does not prevent
 publishing.

Yes, Jeff, and thanks for forwarding this.  To make sure people have
the background...

I announced on 17 Oct to this set of mailing lists that we were
looking for input to the conflict review to be posted to the SAAG
mailing list.  The discussion thread starts here:
http://www.ietf.org/mail-archive/web/saag/current/msg04049.html

On 9 November, I closed the discussion with this message on the SAAG list:
http://www.ietf.org/mail-archive/web/saag/current/msg04164.html

If anyone has any questions about the document, I suggest they contact
the authors directly.  You can do that with the following tools alias:
draft-secure-cookie-session-proto...@tools.ietf.org

Barry, App AD
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Input for conflict review of draft-secure-cookie-session-protocol

[Barry Leiba]

A document titled Secure Cookie Sessions for HTTP has been submitted
to the Independent Stream Editor (ISE):
http://datatracker.ietf.org/doc/draft-secure-cookie-session-protocol/

The IESG has been asked to review the document, as specified in RFC
5742, Section 3.  The Security and Applications Area Directors are
looking for input for that review.  Please post any relevant comments
to the Security Area list, s...@ietf.org, as soon as possible, and at
least by 1 November 2012.

Note: Please do NOT post responses to any of these mailing lists.
Respond only to s...@ietf.org (using the subject line of this
message).

Please read RFC 5742, Section 3, and be aware that we are not looking
for detailed comments on the document itself (see below).  We
specifically need input on whether this document is in conflict with
work that's being done in the IETF.  Look at the five possible
responses specified in that section, and help us determine whether any
of 2 through 5 applies.  Please be specific in your response.

In addition to this, we're sure that the authors and the ISE would
appreciate comments about the document.  If you have those, you may
send them directly to the authors at
draft-secure-cookie-session-proto...@tools.ietf.org
and to the ISE at rfc-...@rfc-editor.org.
General discussion of the document on these lists or the saag list will
likely not get to the authors or the ISE.

Barry Leiba, Applications AD
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] FW: New Version Notification for draft-ietf-oauth-use-cases-02.txt

[Barry Leiba]

 Particularly, the authors are looking for advice with the use of the example
 URLs. Following the guidance of RFC 2606,

 we have used “example” as the top level domain name (e.g., example.com).
 This may mislead readers into thinking that all URLs belong to the same
 organization. A general note, stating that all sites ending with
 “example.com” do not necessarily belong to the same organization, is not
 sufficient (according to some readers). How to avoid the confusion?

You're not using it as the top level domain name.  You're using it as
the second level domain name.  See below.

As Mike says, you can use .net and .org as well as .com.  You can also
use example truly as the top level domain (TLD).  You can use
company1.example and company2.example and
big-university.example, and so on.

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-03.txt

[Barry Leiba]

 Have Section 3 note that certain classes might create new
 sub-registries for what goes under them, if necessary.

 I honestly don't understand the push to have additional registries under
 urn:ietf:params:oauth?

 I agree that one registry is sufficient.  The number of registrations won't be
 huge and so having sub-registries seems like overkill.

No, there was no push; I was just making a suggestion for how things
might be set up.  If there's no need envisoned for sub-registries,
that's fine.

b
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02

[Barry Leiba]

I'd like to see the new version, since there appear to be a bunch of
changes, but first here are some issues that I don't think have been
brought up yet:

The URN registration stuff seems very incompletely baked.  The title
of 5.1 correctly says it's registering a sub-namespace, but the text
incorrectly says that it's creating a registry.  Perhaps IANA will
understand, but I think you need to do this in two parts.  The first
part would register the oauth sub-namespace, and the second would
create a new registry for the things that go into it.

Now, as to what goes into it: What is class?  Is there meant to be a
registry of classes?  Is that what section 5.1 is trying to create
(which should be done in a new section 5.2)?  What initial values are
registered there?

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel

[Barry Leiba]

Phil said...

 **However**  Editorially I feel strongly the comments fall outside the 
 intended scope
 and purpose for this document. This document is about threats specifically 
 related
 to the OAuth protocol.  It's intent is to go beyond security considerations 
 to give
 implementers a feel for the issues the group has considered specific to the 
 protocol.

 Michael's comments are directed at general trusted computing platform. And 
 while I
 agree they are valid, they don't fit in this document.

I'll add one thing to this consideration:  while I agree that we can't
discuss every threat that one might encounter in a web services
environment, I think it's useful and important to discuss issues that
people are likely to think are addressed, mitigated, or solved by
OAuth, *even if we don't think that, and even if we know they're not
really OAuth issues.*

DKIM had a related problem (which I do NOT want to open up for
discussion here; I mention it only for comparison).  DKIM was often
oversold as being something that would block spam or stop phishing
in its tracks.  It will do neither, though it's a tool to be used in
systems that aim at both.  Similarly, while OAuth solves a real
problem and is a good step, it will not *stop* impersonation attacks,
credential-theft attacks, and so on.  We all know that, but many
people who will read the OAuth spec will think it can do that.  The
threats document should be addressing that overselling problem[1],
and if that means highlighting a few things that we think should be
obvious, I'm in favour of it.

I think the things that Mike Thomas has bought up fall into that
category.  I'm sympathetic to the argument that this is a long
document, bordering on (or perhaps having crossed the border into)
tl;dr territory.  Perhaps there are other things that can be
trimmed.  But at this point, I've made a proposal to add a few
paragraphs, and mostly (not completely) gotten feedback from the
editors that my text is acceptable.  Mike has asked for one paragraph
to be added to that, and I think his proposal is reasonable.  If we go
with that set of additions, I think we'll address some of the
overselling problem, and I think the document will be better for it.

If the editors want to post my suggested addition here, they may do
so; yes, it was meant for a small group to iron out first, but the WG
will have to see and agree to it at some point anyway.  If the editors
want to trim a bit elsewhere in the document to make room, they may
also do that -- with the consent of the WG.  But let's please not get
hung up on this to the point of losing traction on the whole document.

And everyone please relax and not get hot or snarky: we're all trying
to make a better document, and calm discussion, rather than sarcasm
and hyperbole, is the best way to do that.  We're almost there.  We'll
get there soon.

Barry, document shepherd
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel

[Barry Leiba]

Oh, and sorry...

 threats document should be addressing that overselling problem[1],
 and if that means highlighting a few things that we think should be
 obvious, I'm in favour of it.

...I forgot to include the footnote.

Barry

[1] Note that I'm NOT saying that the WG is overselling OAuth, but
that any technology like this gets oversold in the press, by
implementors who want to make its support part of a sales pitch, and
by general word of mouth/blog/twit.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Agenda Proposal

[Barry Leiba]

 As far as I know, none of my concerns were incorporated.

Correct, and I will take care of that (or try to) in my shepherd review.

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23

[Barry Leiba]

 I am sorry, but with this language this is a different spec with
 different compliance profiles and without supplying enough guidance
 for creating interoperable server implementations for common
 deployment models.

As I read this thread, I see two things come out clearly:

1. Eran didn't intend to make the change that some read into this, and

2. enough people interpret this as a change that Eran didn't intend
that it's worth fixing.

Everyone agrees on how it should be -- right?  So let's not worry
about whether the text is or isn't confusing, and instead focus on a
small change to the text that will keep the meaning that's intended
and that takes the confusion away from those who think something
drastic has changed.  That should be easy to do, and quick and
non-controversial to wrap up.

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Agenda Proposal

[Barry Leiba]

Oh, and...

 4. MAC Token (TBD)
 https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac/

I believe that in Eran's last communication about this he said that he
does, after all, have the time and inclination to finish it, and would
like to.

b
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23

[Barry Leiba]

 Off list.

Or not so much off list.  He-he.

b
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OK to post updated Bearer spec changing and adding examples?

[Barry Leiba]

 OAuth Chairs,

Changed CC address; please see my list message:
http://www.ietf.org/mail-archive/web/oauth/current/msg08531.html

 Do you approve of posting an updated Bearer spec as below, assuming the
 working group does not object by mid-day Monday?

Yes, that makes sense.

Barry, still chairing for a short time yet

--
From: Mike Jones
Sent: Saturday, March 10, 2012 9:50 AM
To: 'Paul Madsen'; Brian Campbell
Cc: oauth
Subject: RE: [OAUTH-WG] question about the b64token syntax in
draft-ietf-oauth-v2-bearer



I plan to make the change to the example access token value to
mF_9.B5f-4.1JqM before Monday’s submission deadline, per the requests
for b64token syntax clarification.  I’m also considering adding an
access token response example, pre the requests in this thread.  I
would propose adding the following new text for this in a new Section
4 (before the current Security Considerations).  This is largely
parallel to what is done in Section 5.1 of the MAC spec.



4.  Example Access Token Response



Typically a bearer token is returned to the client as part of an OAuth
2.0 [I-D.ietf-oauth-v2] access token response. An example of such as
response is:



 HTTP/1.1 200 OK

 Content-Type: application/json;charset=UTF-8

 Cache-Control: no-store

 Pragma: no-cache



 {

   access_token:mF_9.B5f-4.1JqM,

   token_type:Bearer,

   expires_in:3600,

   refresh_token:tGzv3JOkF0XG5Qx2TlKWIA

 }



Please send either +1s or objections to this text by mid-day Monday.
Unless I receive several +1s, to be conservative at this point, I will
not be including it in Monday’s draft.



-- Mike



From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Paul Madsen
Sent: Wednesday, March 07, 2012 1:34 PM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] question about the b64token syntax in
draft-ietf-oauth-v2-bearer



+1

On 3/7/12 4:08 PM, Brian Campbell wrote:

Yeah, it is case insensitive. I just went with the upper case B

because that's how it was written in §5.1.1 of

draft-ietf-oauth-v2-bearer-17* which is where I guess it's actually

defined. But I see draft-ietf-oauth-v2-23 uses a lower case b**.

Either one would be fine.



I agree that an example response from the token endpoint would be

worthwhile.  Something like the following might help tie together with

the Authorization header example (proposed earlier). It could maybe be

worked in near the top of §2?



 HTTP/1.1 200 OK

 Content-Type: application/json;charset=UTF-8

 Cache-Control: no-store

 Pragma: no-cache



 {

   access_token:vF_9.5dCf-t4.qbcmT_k1b,

   token_type:example,

   expires_in:3600,

   refresh_token:stGzv3xOdkF0X35Qp2TlKWIA,

 }



It'd probably make sense to change the examples in the body §2.2***

and query §2.3 to use the same access token value too.





* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-5.1.1

** http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-7.1

*** http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.2

 http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.3





On Wed, Mar 7, 2012 at 12:00 PM, Justin Richer jric...@mitre.org wrote:

Makes sense to me, except that I think the token_type value is typically

lowercase bearer, though it's defined to be case insensitive in

Oauth-v2-23 section 5.1. Come to think of it, I'm not sure that the value of

this field for the Bearer token type ever got defined anywhere. Section 7.1

references the bearer spec as defining the value of the token_type

parameter, and passes its example as if by reference. Would be worthwhile

giving an example of a token endpoint response, such as what's found in

OAuth-v2-23 section 5.1.



 -- Justin





On 03/07/2012 12:16 PM, Brian Campbell wrote:



I'd like to propose the following changes and additions, derived

largely from Bill and James suggestions, to

draft-ietf-oauth-v2-bearer-17.  These changes have no normative impact

and only aim to add additional clarity and explanation the workings

and implications of the current spec.  I'm definitely open to changes

or improvements in the wording here (not my strong suit by any means)

but I think it's important that these general ideas be conveyed in the

draft.





==  Insert the following text at the beginning of §2:



To make a protected resource request, the client must be in possession

of a valid bearer token. Typically a bearer token is returned to the

client as part of an access token response as defined in OAuth 2.0

[I-D.ietf-oauth-v2]. When the token_type parameter of the access

token response is 

Re: [OAUTH-WG] [apps-discuss] FW: Appsdir review of draft-ietf-oauth-v2-23

[Barry Leiba]

 You have read the spec., and the _only_ concrete thing it tells you
 about the registers is the name of an email list.  So you have to go
 to the email archives and search for . . . what exactly?  Different in
 the three cases above, and in none of them is it obvious how to know
 what counts as success.

The email list is just how you start the registration process.  There
will be an IANA registry for access token types.  When IANA creates
it, the name will be in the published RFC (I expect there'll be a
section in the IANA registries page ( http://www.iana.org/protocols/ )
for OAuth Parameters, and Access Token Types will be listed there;
search that page for DKIM to see what it'll look like).  The spec
also says what will be *in* the registry.

The RFC Editor specifically does NOT want the URL for the registry to
be in the RFC (the URL might change).  But the registry NAME will be
there.

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [apps-discuss] FW: Appsdir review of draft-ietf-oauth-v2-23

[Barry Leiba]

 OK, I now recognise a culture clash as the underlying point at issue,
 so this spec. is the wrong place to address it.

Ah... so if the issue is how IANA makes registry information
available, then please go to the happiana mailing list (
https://www.ietf.org/mailman/listinfo/happiana ) and see if you can
work with Michelle and the other IANA folks on it.

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Reminder: Contacting the chairs

[Barry Leiba]

Because we're in the middle of a chair change, we're having people
contact the chairs by sending email to Hannes and me.  (1) This leaves
Derek out.  (2) If you do this after the Paris meeting, you'll be
sending email to someone who's not an OAuth chair any more.

You can fix this by *always* using the tools alias when you need to
contact the chairs of this or any working group:
oauth-cha...@tools.ietf.org

Use that instead of our individual email addresses.  Replace oauth
with the name of another working group to contact that group's chairs.
 And don't forget the tools. in there.

Barry, OAuth chair for a couple more weeks
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [apps-discuss] FW: Appsdir review of draft-ietf-oauth-v2-23

[Barry Leiba]

Henry says...
 No, I appreciate that you want to use registered short names in the protocol,
 that's just fine.  My problem is that you have left users, developers etc. 
 with
 no way to discover what shortnames have been registered short of a non-
 trivial and error-prone informal search effort.

 What I'm asking for is support for probe URI prefixes for each family of
 shortnames.  So, just as today I use text/n3 as the media type for my
 Notation3 documents, I can check that this is a registered media type by
 attempting to retrieve

  http://www.iana.org/assignments/media-types/text/n3

 and I can see all the registered text types by retrieving from

  http://www.iana.org/assignments/media-types/text

 likewise I ought to be able to check e.g. the bearer token type by
 attempting retrieval from (something along the lines of)

  http://www.iana.org/assignments/access-token-types/bearer

 and I should be able to see all the registered token types by retrieving from

  http://www.iana.org/assignments/access-token-types

 Hope this clarifies what I meant.

Eran says...
 Not sure I understand what you are asking for, but what would the IANA 
 instruction include to support this?

Yeh, I'm not understanding this either.  The spec establishes an
access-token-type registry, and anyone will be able to look in that
registry the same way they look in any other IANA registry, such as
media-types.  It looks like Henry is asking for this to use some sort
of type/subtype mechanism, as media-types does, wherein when a new
token type is registered, that registration or subsequent ones can
create subtypes of that token type.

But it's not clear that such a type/subtype scheme would always apply
here, as it does with media types.  Some token types will have no
subtypes.  What makes more sense is for the token types that need to
create their own sub-registries to do so.  And then those entries will
be found from IANA as well -- no error-prone informal search effort
should be needed.

Or am I missing the same thing Eran is?

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 LC conclusion

[Barry Leiba]

Do you have changes to make based on the Apps and TSV Directorate reviews?

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Last Call: draft-ietf-oauth-v2-23.txt (The OAuth 2.0 Authorization Protocol) to Proposed Standard

[Barry Leiba]

 The IESG has received a request from the Web Authorization Protocol WG
 (oauth) to consider the following document:
 - 'The OAuth 2.0 Authorization Protocol'
  draft-ietf-oauth-v2-23.txt as a Proposed Standard

There are some downrefs in this document that need to be called out in
the Last Call notice, which weren't.

* There is a normative reference to RFC 1750, which will be updated to
point to RFC 4086 before publication.

* There is a normative reference to RFC 2246 (TLS 1.0), which has been
obsoleted by RFC 4346 (TLS 1.1).  The document uses this reference to
note that TLS 1.0 is, at this writing, the most widely deployed
version.  The working group believes it is necessary to note that, and
that the reference be normative.

* There is a normative reference to Informational RFC 2818 (HTTP over TLS).

* There is a normative reference to Informational RFC 4627
(application/json Media Type).

* There is a normative reference to Informational RFC 4949 (Internet
Security Glossary).  This is an allowed downref.

Barry, document shepherd
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base

[Barry Leiba]

 Added to section 1:

   TLS Version

          Whenever TLS is required by this specification, the appropriate 
 version (or versions) of
          TLS will vary over time, based on the widespread deployment and 
 known security
          vulnerabilities. At the time of this writing, TLS version 1.2 xref 
 target='RFC5246' /
          is the most recent version, but has a very limited deployment base 
 and might not be
          readily available for implementation. TLS version 1.0 xref 
 target='RFC2246' / is the
          most widely deployed version, and will provide the broadest 
 interoperability.

          Implementations MAY also support additional transport-layer 
 mechanisms that meet their
          security requirements.

 And referenced this section when TLS requirements were previously defined.

That seems like a very sensible way to organize it; thanks.

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011

[Barry Leiba]

 I have asked you to clearly describe the threat, not the mitigation.

 It obviously was either not clear or convincing the first time and I am not
 going to start digging through emails when you clearly understand it.

To try to shortcut this:
Mike did lay it out clearly, I think, in his first note (which I
linked at the beginning of this thread), and that should be the only
one that needs to be read to understand his point.  The basic point is
that the OAuth framework relies on both the end user and the
authorization server being able to trust the user's UA.  If that winds
up being a compromised browser or a native application that the user
perhaps unwisely installed, all the security in the framework goes out
the window, because an untrustworthy UA can fiddle with pretty much
everything.

Mike's note said much more than that, but I think I've encapsulated
things in an oversimplified version above.  I agree that this is
something that needs to be made very clear... and that I don't see any
way to mitigate it -- it's basically an aspect of what we're working
with here.

I don't think this is a difficult issue to document, and perhaps two
paragraphs should be enough to do it.  Identifying the right place and
the right two paragraphs should be something that a combination of
Mike and the documnet editors can do, if you can do it without getting
on each others' nerves.  :-)

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base

[Barry Leiba]

To close out this issue:
There's disagreement about whether this proposed text is necessary,
but no one thinks it's *bad*, and I see consensus to use it.  Eran,
please make the following change in two places in the base document:

 OLD
 The authorization server MUST support TLS 1.0 ([RFC2246]), SHOULD
 support TLS 1.2 ([RFC5246]) and its future replacements, and MAY
 support additional transport-layer mechanisms meeting its security
 requirements.

 NEW
 The authorization server MUST implement TLS.  Which version(s)
 ought to be implemented will vary over time, and depend on
 the widespread deployment and known security vulnerabilities at
 the time of implementation.  At the time of this writing, TLS version
 1.2 [RFC5246] is the most recent version, but has very limited
 actual deployment, and might not be readily available in
 implementation toolkits.  TLS version 1.0 [RFC2246] is the
 most widely deployed version, and will give the broadest
 interoperability.

 Servers MAY also implement additional transport-layer
 mechanisms that meet their security requirements.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011

[Barry Leiba]

 Working group last call begins today on the threat model document:
 http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01

 Please review this version and post last call comments by 9 December.

Sorry, folks: I got a little behind here.

Working-group last call is now over.  There were no comments in
response to this thread, so it looks like we're mostly done here.
Mike Thomas pointed out to me that his message here:

   http://www.ietf.org/mail-archive/web/oauth/current/msg07780.html

...was in reference to this document -- that might not have been clear
because of the change in subject line.  Torsten, et al, consider that
message to be your only working-group last call comment, and handle it
accordingly.  When that's worked out and there's another version, we
should be ready to send this up to the IESG.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Mandatory-to-implement token type

[Barry Leiba]

Stephen says:
 On 12/02/2011 03:20 AM, Barry Leiba wrote:
 Maybe what would work best is some text that suggests what I say
 above: that toolkits intended for use in implementing OAuth services
 in general... implement [X and/or Y], and that code written for a
 specific environment implement what makes sense for that environment.
 It seems to me that to require any particular implementation in the
 latter case is arbitrary and counter-productive, and doesn't help
 anything interoperate.  Whereas general-purpose toolkits that
 implement everything DO help interop.

 That'd work just fine for me.

OK, so here's what I suggest... I propose adding a new section 7.2, thus:

---
7.2 Access Token Implementation Considerations

Access token types have to be mutually understood among the
authorization server, the resource server, and the client -- the
access token issues the token, the resource server validates it, and
the client is required to understand the type, as noted in section
7.1, above.  Because of that, interoperability of program code
developed separately depends upon the token types that are supported
in the code.

Toolkits that are intended for general use (for building other clients
and/or servers), therefore, SHOULD implement as many token types as
practical, to ensure that programs developed with those toolkits are
able to use the token types they need.  In particular, all general-use
toolkits MUST implement bearer tokens [...ref...] and MAC tokens
[...ref...].

Purpose-built code, built without such toolkits, has somewhat more
flexibility, as its developers know the specific environment they're
developing for.  There's clearly little point to including code to
support a particular token type when it's known in advance that the
type in question will never be used in the intended deployment.
Developers of purpose-built code are encouraged to consider future
extensions and to plan ahead for changes in circumstances, and might
still want to include support for multiple token types.  That said,
the choice of token-type support for such purpose-built code is left
to the developers and their specific requirements.
---

I think that expresses a reasonable compromise that might actually be
followed and might actually do some good.  Comments?  Can we go with
this and close this issue?  (And, sorry, I've been a Bad Chair, and
haven't put this in the tracker.)

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Mandatory-to-implement token type

[Barry Leiba]

 So an MTI token type + no client preference is equivalent to there
 only existing one token type.

 Maybe.

 However, no MTI token type + no client preference = no interop.

I think this exchange, coupled with what you Stephen said in Taipei
(noting that mandatory to implement doesn't mean mandatory to
use), points out a basic difference between how Stephen is thinking
about this and how at least some of the WG participants are.  Let me
see if calling this out helps:

Stephen is thinking that code will be reused.  Perhaps there'll be a
limited number of coded toolkits, and their code will be used to
implement various authorization servers, etc.  That's the way a lot of
Internet code is done today.  In that case, Stephen posits, if we tell
the toolkit writers that they MUST implement X, then at least when X
is being used, implementations based on the different toolkits can
always interoperate.  Lacking that directive, a toolkit that only
implements X will be unable to interoperate with a toolkit that only
implements Y.

Others are thinking that deployed code will be specific to a
particular environment, and it doesn't help at all for that code to
support X if the environment demands Y.  There's no interop benefit
from the MUST implement X directive if the code has been written
specifically for that environment, and, as Mike T says, it only
results in untested code and wasted development time.

I see both sides of this, but in the end I think what Mike says is
spot on, here.  I think it would be very nice to strongly encourage
toolkit writers to support all the available options, but there's
absolutely no reason to require, and no benefit in requiring,
purpose-built code to do anything of the sort.

Maybe what would work best is some text that suggests what I say
above: that toolkits intended for use in implementing OAuth services
in general... implement [X and/or Y], and that code written for a
specific environment implement what makes sense for that environment.
It seems to me that to require any particular implementation in the
latter case is arbitrary and counter-productive, and doesn't help
anything interoperate.  Whereas general-purpose toolkits that
implement everything DO help interop.

Barry, as participant
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base

[Barry Leiba]

 The OAuth base doc refers in two places to TLS versions (with the same
 text in both places:

 OLD
 The authorization server MUST support TLS 1.0 ([RFC2246]), SHOULD
 support TLS 1.2 ([RFC5246]) and its future replacements, and MAY
 support additional transport-layer mechanisms meeting its security
 requirements.

 In both the shepherd review and the AD review, this was called into question:
 1. MUST for an old version and SHOULD for the current version seems wrong.
 2. Having specific versions required locks us into those versions (for
 example, all implementations will have to support TLS 1.0, even long
 after it becomes obsolete, unless we rev the spec.

The comments I've gotten on this show a clear consensus against the
change I suggest, and against any attempt to require a version of TLS
other than 1.0.  I still, though, am concerned that locking this spec
into TLS 1.0 is limiting.  So let me propose an alternative wording,
which again tries to make the version(s) non-normative, while making
it clear which version(s) need to be implemented to get
interoperability:

NEW

The authorization server MUST implement TLS.  Which version(s)
ought to be implemented will vary over time, and depend on
the widespread deployment and known security vulnerabilities at
the time of implementation.  At the time of this writing, TLS version
1.2 [RFC5246] is the most recent version, but has very limited
actual deployment, and might not be readily available in
implementation toolkits.  TLS version 1.0 [RFC2246] is the
most widely deployed version, and will give the broadest
interoperability.

Servers MAY also implement additional transport-layer
mechanisms that meet their security requirements.


Comments on this version?

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Meeting minutes from IETF 82

[Barry Leiba]

The chairs have posted minutes to the meeting materials page.  Find them here:
http://www.ietf.org/proceedings/82/minutes/oauth.txt

A few messages will follow soon, with action items from the meeting.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011

[Barry Leiba]

Working group last call begins today on the threat model document:
http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01

Please review this version and post last call comments by 9 December.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Mandatory-to-implement token type

[Barry Leiba]

Stephen, as AD, brought up the question of mandatory-to-implement
token types, in the IETF 82 meeting.  There was some extended
discussion on the point:

- Stephen is firm in his belief that it's necessary for
interoperability.  He notes that mandatory to *implement* is not the
same as mandatory to *use*.
- Several participants believe that without a mechanism for requesting
or negotiating a token type, there is no value in having any type be
mandatory to implement.

Stephen is happy to continue the discussion on the list, and make his
point clear.  In any case, there was clear consensus in the room that
we *should* specify a mandatory-to-implement type, and that that type
be bearer tokens.  This would be specified in the base document, and
would make a normative reference from the base doc to the bearer token
doc.

We need to confirm that consensus on the mailing list, so this starts
the discussion.  Let's work on resolving this over the next week or
so, and moving forward:

1. Should we specify some token type as mandatory to implement?  Why
or why not (*briefly*)?

2. If we do specify one, which token type should it be?

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] TLS version requirements in OAuth 2.0 base

[Barry Leiba]

The OAuth base doc refers in two places to TLS versions (with the same
text in both places:

OLD
The authorization server MUST support TLS 1.0 ([RFC2246]), SHOULD
support TLS 1.2 ([RFC5246]) and its future replacements, and MAY
support additional transport-layer mechanisms meeting its security
requirements.

In both the shepherd review and the AD review, this was called into question:
1. MUST for an old version and SHOULD for the current version seems wrong.
2. Having specific versions required locks us into those versions (for
example, all implementations will have to support TLS 1.0, even long
after it becomes obsolete, unless we rev the spec.

I have suggested the following change, as doc shepherd:

NEW
The authorization server MUST implement the current version of TLS
(1.2 [RFC5246] at the time of this writing), and SHOULD implement the
most widely deployed previous version (1.0 [RFC2246] at the of this
writing), unless that version is deprecated due to security
vulnerabilities.  It MAY also implement additional transport-layer
mechanisms that meet its security requirements.

I believe this also gives us the effect we want, without the two
problems above.  There was consensus in the meeting for accepting this
text.  Confirming on the list:

Please respond to this thread if you *object* to this change, and say
why.  Please respond by 2 Dec 2011.

Barry, as document shepherd
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base

[Barry Leiba]

 Please refer to this thread about the problem with requiring anything more
 than TLS 1.0
 http://www.ietf.org/mail-archive/web/oauth/current/msg07234.html

 You will end up with a spec that virtually no one can implement and be in
 conformance with. I still have yet to find an implementation out in the wild
 that supports anything more than TLS 1.0

Are you saying that there's some difficulty in *implementing* TLS 1.2
?  If so, please explain what that difficulty is.

If you're saying that TLS 1.2 is not widely deployed, and so it's hard
to find two implementations that will actually *use* TLS 1.2 to talk
to each other, I have no argument with you.  But that's not the point.
 If everyone implements only TLS 1.0, we'll never move forward.  And
when TLS 1.2 (or something later) does get rolled out, OAuth
implementations will be left behind.  If everyone implements 1.2 AND
1.0, then we'll be ready when things move.

I'm pretty sure there'll be trouble getting through the IESG with a
MUST for something two versions old, and a SHOULD for the current
version.

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Rechartering

[Barry Leiba]

 do we have the band width to work on all these items, as some are
 big and some are fairly small and contained. May have to have some
 prioritized list of where people think these fit.

Yes, exactly.  And one of the things we'd like to hear from all of you
is what your priorities are... how you would prioritize the list.

Barry, chair-like object
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Possible alternative resolution to issue 26

[Barry Leiba]

 Existing practice is that simple ASCII strings like email profile,
 openid, etc. are used as scope elements.  Requiring them to be URIs
 would break most existing practice.

 Constraining syntax to an ascii token OR a URI (relative reference) might
 work.  Anything with a colon can be interpreted as a URI; anything without
 better use a constrained set of characters.

This sounds like a good compromise.  URI encoding is already specified
elsewhere, and then ASCII tokens can be limited as they already are,
with no encoding.

Are there any objections to this approach?

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Proposed resolution for issue 26

[Barry Leiba]

 My proposed resolution is that %-encoding not be required in the
 specification

I agree with your analysis, now that I see it laid out clearly.  I
would feel better, though, if there were text in the document that
explained that to others, who read it later.  Perhaps, using your
words, we could make this change to section 2.4:

OLD
   The scope attribute is a space-delimited list of scope values
   indicating the required scope of the access token for accessing the
   requested resource.  The scope attribute MUST NOT appear more than
   once.

NEW
   The scope attribute is a space-delimited list of scope values
   indicating the required scope of the access token for accessing the
   requested resource.  The scope attribute MUST NOT appear more than
   once.

   Interpretation of scope strings requires semantic agreement on the
   meaning of the scope strings between the parties participating the
   OAuth flow.  Should an encoding be used for scope strings in a
   particular deployment context, participants have to have agreed
   upon that encoding, just as they agree on other OAuth configuration
   parameters.

Does that work?

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Publication requested for draft-ietf-oauth-v2-22

[Barry Leiba]

Stephen,
The OAuth working group requests publication of draft-ietf-oauth-v2-22
as Proposed Standard.

The PROTO writeup is in the tracker:
https://datatracker.ietf.org/doc/draft-ietf-oauth-v2/

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Reviewing draft-ietf-oauth-v2-21

[Barry Leiba]

As you've all probably seen, Eran has posted version 21 of the OAuth
base spec, in which he believes he's addressed all comments and issues
that came up in the review of version 20.  We should be ready to send
this to the IESG.

Everyone who had comments or issues, please review -21 and make sure
that your concerns have been handled to your satisfaction (or that
there was no consensus to make a change).  And we encourage everyone
to review the changes from -20 to -21, to make sure Eran didn't
inadvertently break anything along the way.

The -21 is here:  http://tools.ietf.org/html/draft-ietf-oauth-v2-21
And diffs from -20 can be found here:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-21.txt

We'll give it until the end of next week, while I work on the shepherd
writeup.  Comments, please, by 16 September.  A few affirmative notes
saying, Yes, I reviewed it and it looks good, will also be helpful.
Keep in mind, as you review, that pet changes are out of scope at this
point.  We're just reviewing -21 to make sure (1) it doesn't break
anything from -20, and (2) it isn't missing anything that was brought
up in WGLC.  New issues will have to be very serious, indeed, in order
to be considered now.

Also, a note on the thread that Mike Thomas started about the OAuth
problem statement and threats:
I did encourage him to start the discussion, and I think it can be a
useful conversation.  I do NOT think it will or should result in a
change to the base spec, but it might feed into the threat model
document (draft-ietf-oauth-v2-threatmodel), as Torsten, et al, move
that toward completion.  Remember that the base spec encourages
readers to refer to the threat model document for more detailed
descriptions of threats and attacks.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Auth Code Swap Attack

[Barry Leiba]

 I believe we have full consensus on this approach.

I agree, and I will close the issue.

Barry, happy chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OMA Liaison Has Arrived! scope-v

[Barry Leiba]

 +1 for Jame's feedback here.  We need to solve this.

I have opened an issue in the tracker on this:
http://trac.tools.ietf.org/wg/oauth/trac/ticket/26

I intend to add the following to the response to this item:
The working group understands that client code needs to know whether
to use and decode percent-encoding.  The issue is being discussed and
tracked, and will be resolved before the final version of the bearer
document is produced.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)

[Barry Leiba]

 I'd like to ask the chairs to open an issue for this.

http://trac.tools.ietf.org/wg/oauth/trac/ticket/24

 I didn't realize how hyper sensitive this working group has become that every
 proposal being questioned needs a ticket to prove to people that they are not
 being dismissed.

It's OK: tickets are cheap, and I don't mind... and if it helps people
to know that discussions that aren't quickly resolved are being
tracked, then that's what the issue tracker is there for.  It makes
sure things don't get forgotten, and reminds people what to look more
closely at in the next doc rev.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)

[Barry Leiba]

 Yes, the example I provided is a very lightweight one which does take the
 form of CSRF, but it is only the simplest example of a family of automated
 authorization flow attacks. Indeed, a nonce (or hidden token, both serve the
 same purpose in this case) would be enough here.

 Great. So we need to add explicit text about preventing CSRF attacks at the
 authorization endpoint.

General comment, not for this issue alone (and not specifically to the
folks conversing here):

There are a great many things we can say about threats and attacks,
which is why we have the threats document by Torsten, et al.  I'm
generally in favour of putting more security considerations into the
base document to describe threats that implementors need to be
concerned about, and well-crafted text that the editors can drop in is
a good thing.

That said, the reason we decided to put highlights into the base
doc's Security Considerations section, and then refer to the larger
document for more details and a more complete threat analysis is that
we wanted to strike a balance, keep the base doc for protocol details,
and leave the threat descriptions in the base doc as general threat
*classes*.

As we debate the various attack descriptions and mitigations that we
might like to add, please keep that balance in mind, and think
carefully about whether the details of *this specific* attack should
go into this document, or whether we just need to cover the general
class of threats here and put the details of this attack into
draft-ietf-oauth-v2-threatmodel.

Otherwise, we might eventually merge the entire threat analysis
document into the base, one paragraph at a time.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OMA Liaison Has Arrived! scope-v

[Barry Leiba]

The text for the answer below came from Mike, as the chairs asked for
at the IETF 81 meeting.  Mike, do you have a response to James's
issue?  Can we give a better response here?  Should the bearer doc
specify %-encoding explicitly?

Barry

On Thu, Aug 18, 2011 at 7:15 AM, Manger, James H
james.h.man...@team.telstra.com wrote:
 *    For bearer tokens: clarification whether the non-support of percent
 encoding for scope-v element of WWW-Authenticate Response Header Field
 grammar is intentional.

 Answer:
 In the bearer token document (Section 2.4 of
 draft-ietf-oauth-v2-bearer-08, The WWW-Authenticate Response Header
 Field), the scope-v element is unambiguously defined to allow a
 specific set of characters.  That set of characters does permit, but
 does not mandate, support for percent-encoding of characters.


 This is a poor answer.
 A client app receiving a scope value in an WWW-Authenticate: Bearer 
 scope=... response will either compare it with strings from a OAuth2 
 JSON-encoded token response, or copy it into a request to an authorization 
 server. It needs to know if it needs to %-decode the value or not before 
 doing these things. Clients cannot be expected to behave differently for 
 different servers in this respect.

 OAuth2 core (implicitly) allows a scope to use any Unicode char except space 
 (as space is used as a delimiter).
 Bearer restricts scopes to 93 ASCII chars.
 OMA are asking if this is intentional.

 If we really want to restrict scope values it would be better done in OAuth2 
 core.
 If we don't want to restrict values then the bearer spec needs to be able to 
 handle any possible scope value by defining an escaping mechanism for scope-v 
 (or by not having a scope parameter).

 --
 James Manger
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OMA Liaison Has Arrived!

[Barry Leiba]

I'm sorry for the delay in getting this written.  Because of the
delay, the working group has just a short time to review my proposed
response, below.  Everyone, please have a look at the answers I
propose to send, and post any objections to this thread by the end of
the day on Monday, 22 August.  Hannes, please also check with the IAB
in parallel, and make sure we can send this via Murray as soon as
we've resolved any WG objections.

Barry, as chair

-

The IETF OAuth working group thanks OMA ARC SEC for the liaison
statement titled OAuth discovery and specification availability,
dated 18 July 2011.

The OMA liaison statement asks the OAuth working group to address five
issues, and our answers are as follows:

•   Availability of the IETF OAuth specifications: especially
[draft-ietf-oauth-v2] and [draft-ietf-oauth-v2-bearer], and also
[draft-hammer-oauth-v2-mac-token],
[draft-lodderstedt-oauth-revocation] and [draft-recordon-oauth-v2-ux].

Answer:
The IETF cannot guarantee publication dates, but we can give some
best-guess timeframes.  As this writing, draft-ietf-oauth-v2 and
draft-ietf-oauth-v2-bearer have completed Working Group last call and
are undergoing their final revisions before being sent to the IESG.
We expect the final versions of those documents to be in the RFC
Editor queue around the end of September, though it could be later if
issues come up in IETF-wide last call or during IESG evaluation.  The
draft-hammer-oauth-v2-mac-token document has been replaced by
draft-ietf-oauth-v2-http-mac, which is a working group document.  It
is likely to be in the RFC Editor queue by the end of the year.

The remaining two documents are not working group documents, and the
working group can say nothing about their status.  The OAuth working
group intends to revise its charter in the November timeframe, and
it's possible that one or both of those documents could be adopted by
the working group at that time, and we could have further information
about target publication dates then.

•   Availability of the OAuth Parameters Registry

Answer:
The draft-ietf-oauth-v2 document establishes the OAuth Parameters
Registry (in section 11.2, as of draft version 20).  The registry will
be available when the RFC is published, which will be some time after
the document goes into the RFC Editor queue, depending upon the RFC
Editor's load at the time.

•   IETF intent to specify an OAuth Discovery mechanism

Answer:
There is interest among OAuth working group participants for
specifying such a mechanism, but the work is not in the current
charter.  It will likely be considered during the aforementioned
charter update in (approximately) November.

•   Considerations that can help implementors decide about the type of
OAuth access token to deploy.

Answer:
There is no current work planned, but documents with such
implementation advice might also be considered during the rechartering
discussion.

•   For bearer tokens: clarification whether the non-support of percent
encoding for scope-v element of WWW-Authenticate Response Header Field
grammar is intentional.

Answer:
In the bearer token document (Section 2.4 of
draft-ietf-oauth-v2-bearer-08, The WWW-Authenticate Response Header
Field), the scope-v element is unambiguously defined to allow a
specific set of characters.  That set of characters does permit, but
does not mandate, support for percent-encoding of characters.

-
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Auth Code Swap Attack

[Barry Leiba]

On Mon, Aug 15, 2011 at 10:51 AM, Anthony Nadalin tony...@microsoft.com wrote:
 That's nice, four people come up with text and you decide to use your text.
 Making state optional does nothing to fix the protocol issue, people will get
 this wrong and have. Our developers have been through this and agreed
 upon the text that was generated. They find the text in the current draft
 unacceptable and confusing and think that new text is acceptable.

I have to agree with what Tony says above.  The text proposed in his
message was agreed upon by several WG participants, and unless there's
some significant objection to it I think we should use it in the -21
version, subject to final WG review.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Auth Code Swap Attack

[Barry Leiba]

 I'll ask the chairs to open an issue for this.

The chairs consider themselves asked, and have opened a ticket:
http://trac.tools.ietf.org/wg/oauth/trac/ticket/23

 My proposed requires CSRF protected without adding additional requirements,
 and therefore, is within the scope of my editorial discretion. IOW, my text is
 already well-within working group consensus. Your text has not established
 consensus, and I have listed actual issues with the proposed text which none
 of the authors have addressed so far.

This chair disagrees with the editorial prerogative at this point.  I
have not discussed this with my co-chairs, and perhaps they don't
agree with me.

I agree with Eran that the issue isn't settled -- that the
Tony/Yaron/Torsten/Phil text, and the normative change it proposes,
does not yet have WG consensus.  And I note Eran's objection and the
reasons for it, and I agree that it needs more discussion.

But I believe the T/Y/T/P proposal has enough backing that it's the
one that should be floated in the next version of the document right
now.  That by no means makes it final, and the chairs will track the
discussion and make a proper consensus judgment at the appropriate
time.

I also think it's perfectly acceptable for the editor to put both
versions of the text in, with a note that the WG must choose which way
to go.  Eran, is that a path you can tolerate?

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Auth Code Swap Attack

[Barry Leiba]

 I do not plan to publish another draft until this issue is closed and 
 resolved.
 I plan to seek WG consensus to every change made to -21 prior to publication
 to reduce the need for another WG draft.
...
 and I informed the list of my intention of using the edited text. Mr. Nadalin 
 then
 raised his disagreement with the proposed edit. Fine. Now we wait for more
 participants to express their views.

OK, this is where the disconnect came from, and why I had a problem
with what I heard.  My guess is that that's the same problem Tony had:
My interpretation of your one-line message that said, I'm using my
proposed text in -21, was that you were deciding the issue, and were
about to publish a new draft now-ish that reflects your decision.
What you say here makes it clear that that's not the case, and that
what you meant was, I believe my proposed text addresses this issue
while maintaining established consensus about the protocol details,
and when I post -21 (soon, but not now), which I hope will be the
final version, I intend to use that version of the text, unless
further discussion shows that WG consensus on the 'state' option has
now changed.

That's rather more long-winded, of course, but I have, as chair, no
problem at all with that plan.  I also suspect that Tony will consider
the longer-winded explanation to be less dismissive of the T/Y/T/P
proposal than the one-sentence version may have come across.

And, so, carry on.

Barry, still chair-like
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Refresh Tokens

[Barry Leiba]

This seems to need a chair to step in.  Tony is taking a strong stand
and maintaining it:

On Thu, Aug 11, 2011 at 1:40 PM, Anthony Nadalin tony...@microsoft.com wrote:
 Nowhere in the specification is there explanation for refresh tokens, The
 reason that the Refresh token was introduced was for anonymity. The scenario
 is that a client asks the user for access. The user wants to grant the
 access but not tell the client the user's identity. By issuing the refresh
 token as an 'identifier' for the user (as well as other context data like
 the resource) it's possible now to let the client get access without
 revealing anything about the user. Recommend that the above explanation be
 included so developers understand why the refresh tokens are there.

So far, though it's been only half a day, I've seen several posts
disagreeing with Tony, and none supporting any change to the text for
this.  We're close to ending WGLC, so please post here if you agree
with Tony's suggested change.  Otherwise, it looks like consensus is
against.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Security area review

[Barry Leiba]

 But this still puzzles me. After two years in the application area where IMO 
 this
 working clearly belongs, we were moved to the security area under the premise
 of increased review and engagement from the security area.

I can't speak for the IESG, and it's they who made the decision to
move the WG.  But I can say that I disagree that it clearly belongs
in the App area.  From the start, I was puzzled why it wasn't
chartered in the Sec area; OAuth is, to me, a security protocol that's
used at the app layer (as opposed to an app protocol that happens to
include security).  DKIM was in a similar situation -- having bits in
both areas -- and in 2006 was chartered in Sec... and that one seemed
even more that it should have been in Apps.

We have puzzling situations often, these days, where working groups
clearly belong in more than one area, and the way things currently
work, the IESG has to choose.  ALTO might have been in RAI or App, was
chartered in App, and now is in TSV.  We've had a few recently
chartered WGs where there was some debate about which area they belong
in.  I've thought for some time that we should have multi-area WGs,
but that's not the case now.

Don't pay too much attention to which AD manages the WG.

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Security area review

[Barry Leiba]

 Did the chairs issue a last call request to anyone in the security area? I
 thought the whole point of moving this working group from apps to security
 was to increase the review and participation of that area. So far I have
 seen absolutely nothing to indicate any such contribution. I would like to
 know what actual actions are being taken to turn this promise into reality.

There'll be a security directorate review when we send the doc to the
IESG.  I can certainly ask Sam to schedule a review now, instead of
waiting, and I'll do that.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MAC Tokens body hash

[Barry Leiba]

On Tue, Aug 2, 2011 at 2:22 AM, Eran Hammer-Lahav e...@hueniverse.com wrote:
 I am going to drop both ‘bodyhash’ and ‘ext’, and instead add ‘app’. ‘app’
 allows you to include any data you want. ‘ext’ without an internal format
 and register is just asking for trouble, and I have no intention of adding
 that level of complexity. There are other proposals in the IETF for full
 HTTP message signatures, and I’ll leave these more complex use cases to
 them.

 If you can demonstrate actual need (with examples) of both ‘app’ and ‘ext’,
 I’m willing to reconsider but you can clearly accomplish the same end result
 with just one, application-specific parameter.

Just a word of process stuff, here: draft-ietf-oauth-v2-http-mac is a
working group document, not an individual submission.  That means that
the working group decides what gets changed, and we need to see
consensus to make a change like this.  I am going to, I have no
intention of, and I'm willing to reconsider aren't appropriate.

It might be that making this change is the right thing to do, but so
far we have no one voicing support for the change (Skylar responded
favourably to the initial message, but no one's supported removing
ext in favour of app).  Let's have more discussion before any
decisions are made.  And, in general, for all documents, let's please
have editors making suggestions, not pronouncements.  Tone is
important.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-urn-sub-ns-00.txt

[Barry Leiba]

On Sat, Jul 30, 2011 at 12:47, Peter Saint-Andre stpe...@stpeter.im wrote:
 On 7/29/11 3:07 PM, Brian Campbell wrote:
 Following up from
 http://www.ietf.org/mail-archive/web/oauth/current/msg06949.html a few
 weeks ago, I've submitted a new I-D to establish an IETF URN
 Sub-Namespace for OAuth (urn:ietf:params:oauth:*:*).  Eran balked at
 putting this in the core spec so it made sense to produce a separate
 draft for it.  I'd like to request from the group and the chairs that
 this draft become a work item of the WG as soon as possible. The SAML
 draft will utilize this to register a proper URN for the extension
 grant type and presumably the JWT draft will as well.   Hopefully it
 will be useful in other contexts as well (like the oob parameter that
 has been discussed).

 The draft is available at:
 http://tools.ietf.org/html/draft-campbell-oauth-urn-sub-ns-00

 Because Hannes originally wrote all the content, I've listed him as an
 author. Let me know if that's not appropriate.

 I'm happy to sponsor this draft if the Security ADs think it is too
 appsy, but I think it's completely straightforward.

Given the progress that the OAuth WG has made, the fact that we're in
WGLC on two major documents, and the fact that the SAML draft depends
upon what's in here, I have no issue with adding this as a WG item.
Stephen, do you agree with that?  (I know that Stephen's away for a
bit, and won't be responding for a while.  This can wait until he gets
back, and in the meantime the SAML doc can assume that this one is
going forward.)

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Minutes from IETF 81 meeting

[Barry Leiba]

I have uploaded minutes to the meeting materials page, and they can be
found here:
http://www.ietf.org/proceedings/81/minutes/oauth.txt

Corrections, please; and thanks to Tony Nadalin for taking notes.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-07.txt

[Barry Leiba]

 This version should be the subject of the working group last call.

As announced in the working group session this morning at IETF 81:

This document goes into working-group last call today, ending on 12
August.  Everyone: please review this version of the document, and
make any comments by 12 August.  The goal will be to have Mike
incorporate any comments at that point, put out a final version, and
send it to the IESG.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Draft -20

[Barry Leiba]

As announced in the working group session this morning at IETF 81:

This document goes into working-group last call today, ending on 12
August.  Everyone: please review this version of the document, and
make any comments by 12 August.  The goal will be to have Eran
incorporate any comments at that point, put out a final version, and
send it to the IESG.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call For Agenda Items for IETF#81

[Barry Leiba]

I have updated the agenda, which should now be final and can be found here:
http://www.ietf.org/proceedings/81/agenda/oauth.txt

I have slides only for the sidejacking attack discussion.  Does no one
have slides for discussion of document issues?  Perhaps this will be a
short meeting, because there's nothing to discuss

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types

[Barry Leiba]

 Looks like we have consensus for the new text. I'd like to ask the chairs
 to close issue 18 (or note it resolved until the I-D freeze is over and I can
 push a revised draft).

I agree; it looks like folks are happy with this text.  I'll close
this one as well.  If there's a problem in the -19 version of the
draft, we can re-open it.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call For Agenda Items for IETF#81

[Barry Leiba]

Having not received any slides yet, I'm repeating this:

 Presenters will be asked to have presentation slides in to the chairs
 by the end of the day Saturday, 23 July, so we can post them to the
 meeting materials page with plenty of time for all participants to
 review them.

 Meeting materials page: https://datatracker.ietf.org/meeting/81/materials.html

Please get slides to us by tomorrow.  It really helps the remote
participants, as well as the chairs.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Request to close issues

[Barry Leiba]

 What about my comments?

 http://www.ietf.org/mail-archive/web/oauth/current/msg07030.html
 http://www.ietf.org/mail-archive/web/oauth/current/msg07031.html
 http://www.ietf.org/mail-archive/web/oauth/current/msg07032.html

Sorry; I have asked Eran off list about them.  What doesn't get
addressed in -19 can be re-opened at your request.

Barry
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Request to close issues

[Barry Leiba]

 What about my comments?

 http://www.ietf.org/mail-archive/web/oauth/current/msg07030.html
 http://www.ietf.org/mail-archive/web/oauth/current/msg07031.html
 http://www.ietf.org/mail-archive/web/oauth/current/msg07032.html

 Sorry; I have asked Eran off list about them.  What doesn't get
 addressed in -19 can be re-opened at your request.

To be clear: this was a chair error, reading  processing messages in
the wrong order.

Barry, as fallible chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-v2-18

[Barry Leiba]

 List of open issues:

 * Consensus for new Client Registration section (2)
 * Consensus for revised Redirection URI section (3.1.2)
 * Consensus for new token endpoint Client Authentication section (3.2.1)
 * Consensus for new authorization endpoint response type extensibility (8.4)

These issues have been open for almost a week -- they're issues 15
thru 18 in the tracker:
   http://trac.tools.ietf.org/wg/oauth/trac/report/1

There's already text in draft-ietf-oauth-v2-18 for them, marked as
pending consensus, so we have only to confirm that the text is
acceptable to the working group.  There's been no discussion of that
text that I've seen, and I take that to mean that what's there looks
good.

We'll give it another few days, and take silence to mean assent.  In
other words, if anyone has problems with the pending consensus text,
please start a new thread about it, and put the issue number in the
subject line (Subject: Issue 15, new client registration, for
example).  Barring objections by this coming Tuesday afternoon (19
July), I will close issues 15 thru 18.

As soon as we get resolutions for issues 19 thru 21, we'd like to
start working group last call on draft-ietf-oauth-v2.  So let's get
all the issues sorted out as soon as we can, and move this document
ahead.

Issues 19 thru 21:
 * Missing example from security section 10.4 Refresh Tokens
 * Missing reference to DOM variable example in section 10.12 Cross-Site
   Request Forgery
 * Need editing for 10.13 Clickjacking to better align with the protocol 
 terminology,
   missing reference for x-frame-options header

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-v2-18

[Barry Leiba]

 List of open issues:

 * Consensus for new Client Registration section (2)
 * Consensus for revised Redirection URI section (3.1.2)
 * Consensus for new token endpoint Client Authentication section (3.2.1)
 * Consensus for new authorization endpoint response type extensibility (8.4)
 * Missing example from security section 10.4 Refresh Tokens
 * Missing reference to DOM variable example in section 10.12 Cross-Site
   Request Forgery
 * Need editing for 10.13 Clickjacking to better align with the protocol 
 terminology,
   missing reference for x-frame-options header

 (This is the complete list. If you have an issue not listed you must raise it 
 again
 as it is not being tracked.)

I have put this list into the datatracker:
http://trac.tools.ietf.org/wg/oauth/trac/report/1

Please let me know as they get resolved, so I can update it.  Also, if
you open new threads for new issues, please make it clear that you're
asking for a new issue to be created.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Timely review request: pre-draft-17

[Barry Leiba]

On Thu, Jul 7, 2011 at 4:01 AM, Eran Hammer-Lahav e...@hueniverse.com wrote:
 -17 will be published by Friday at which point I will leave it to
 the chairs to decide if they still want to initiate WGLC or give
 the draft a few days of informal review.

Working-group last call can cover all reviews of this.  It's a less
formal thing than IETF last call, which the IESG will initiate
later... and we can recycle the document and do another WGLC if it
turns out that we got something so seriously wrong that it's
necessary.

And I'd like to take this opportunity to say that the chairs are happy
with the progress, and we thank everyone for the careful reviews, and
for working together to get this work wrapped up.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Reminder of draft submission deadlines

[Barry Leiba]

Important reminder to all draft editors:

The deadline for submissions of -00 version drafts is TODAY, 4 July,
at 17:00 PDT (23:59+ UTC).

The deadline for submissions of later version drafts is NEXT MONDAY,
11 July, at 17:00 PDT (23:59+ UTC).

Please don't miss the deadlines if you have drafts to submit.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New draft on UMA Core protocol --- FW: I-D Action: draft-hardjono-oauth-umacore-00.txt

[Barry Leiba]

 FYI This is a new draft on the UMA Core protocol, which builds on OAuth2.0.

 Hopefully we can present/discuss it at IETF81 in Quebec City.

The chairs will be happy to accept a presentation/discussion on this
as time permits.  That means it will go at the end of the agenda, and
we will only get to it if other discussions finish with enough time
for this.

It would help if you sent us slides to include in the meeting
materials.  We'll include them in the materials whether or not there's
time to present and discuss them, so they'll be part of the permanent
record, and so people can look them over.

I expect that we'll set the deadline for slide submissions at end of
day Friday, 22 July.  Send them to the chairs at
oauth-cha...@tools.ietf.org.

Barry, as chair
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth