Re: [OAUTH-WG] Diversity and Inclusiveness in the IETF

[Eric Rescorla]

Replying to Rifaat's e-mail but not replying to him specifically.

Hi folks,

I don't think the question of whether OAuth is a good or bad WG group is
really a productive one in general, and it's especially hard for me to see
how it's going to let us make progress on questions of DEI. This seems like
precisely the kind of thing that's going to lead to a bunch of hard
feelings without making progress. I think we can all agree that the IETF
culture isn't perfect and that there are cases where we make it hard for
new people to get involved, so maybe we could focus instead on those
aspects of our culture.

I would suggest that if people have problems with the way the OAuth WG is
being run they ought to take it up with the AD (Roman Danyliw), or, failing
that, on the IETF list.

-Ekr




On Tue, Feb 23, 2021 at 2:12 PM Rifaat Shekh-Yusef 
wrote:

>
> On Tue, Feb 23, 2021 at 4:57 PM Mark Nottingham  wrote:
>
>>
>>
>> > On 24 Feb 2021, at 2:20 am, Kathleen Moriarty <
>> kathleen.moriarty.i...@gmail.com> wrote:
>> [...]
>> > And way back when I was AD, OAuth was by far the most productive
>> working group I managed.  They put out what felt like about 3 documents a
>> meeting for full publication.  I was the AD for 3 years, ending in 2017
>> when EKR became an AD.
>> >
>> > There was a bit of management as a result of the number of experts and
>> varying use cases for their environments, but even with that, OAuth was
>> very productive.  Since your document was 2016, I was likely the AD.  Yes,
>> the meetings had challenges at times, but we worked through it and things
>> got done.
>>
>> Measuring productivity through the number of documents published is not a
>> good habit for us to get into;
>
>
> The number of documents published was in response to a comment that
> "nothing would get done" at the OAuth WG. Which is clearly not true.
>
>
>> it gives incentive to all of the wrong kinds of behaviours.
>
>
> Can you elaborate on these wrong behaviours?
>
> Regards,
>  Rifaat
>
>
>> Having some success metrics for our work has come up in the IAB a few
>> times, but we haven't made much progress.
>>
>> Cheers,
>>
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>> ___
>> 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] Fwd: AD Review of draft-ietf-oauth-jwt-bcp

[Eric Rescorla]

CCing the WG because I was wrong about the aliases.

-- Forwarded message -
From: Eric Rescorla 
Date: Sun, Aug 26, 2018 at 2:02 PM
Subject: AD Review of draft-ietf-oauth-jwt-bcp
To: oauth 


Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4649


COMMENTS
S 1.2.
>   1.2.  Conventions used in this document
>
>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>  "OPTIONAL" in this document are to be interpreted as described in
>  [RFC2119].

You will want to cite 8174 here.


S 2.6.
>
>   2.6.  Substitution Attacks
>
>  There are attacks in which one recipient will have a JWT intended for
>  it and attempt to use it at a different recipient that it was not
>  intended for.  If not caught, these attacks can result in the

I don't understand this attack. Can you go into more detail?


S 3.2.
>  Therefore, applications MUST only allow the use of cryptographically
>  current algorithms that meet the security requirements of the
>  application.  This set will vary over time as new algorithms are
>  introduced and existing algorithms are deprecated due to discovered
>  cryptographic weaknesses.  Applications must therefore be designed to
>  enable cryptographic agility.

Is this must normative?


S 3.2.
>  may be no need to apply another layer of cryptographic protections to
>  the JWT.  In such cases, the use of the "none" algorithm can be
>  perfectly acceptable.  JWTs using "none" are often used in
>  application contexts in which the content is optionally signed; then
>  the URL-safe claims representation and processing can be the same in
>  both the signed and unsigned cases.

I think you probably need to have a clearer "don't use none by
default" statement here.


S 3.4.
>  ECDH-ES ephemeral public key (epk) inputs should be validated
>  according to the recipient's chosen elliptic curve.  For the NIST
>  prime-order curves P-256, P-384 and P-521, validation MUST be
>  performed according to Section 5.6.2.3.4 "ECC Partial Public-Key
>  Validation Routine" of NIST Special Publication 800-56A revision 3
>  [nist-sp-800-56a-r3].

Is there an X25519 specification for JWE? If so, you should probably
specify the appropriate checks.


S 3.5.
>   3.5.  Ensure Cryptographic Keys have Sufficient Entropy
>
>  The Key Entropy and Random Values advice in Section 10.1 of [RFC7515]
>  and the Password Considerations in Section 8.8 of [RFC7518] MUST be
>  followed.  In particular, human-memorizable passwords MUST NOT be
>  directly used as the key to a keyed-MAC algorithm such as "HS256".

If you can't use them "directly" than how should you use them? Do you
want to say anything about password hashing (argon, etc.)?


S 3.12.
> of JWTs.
>
>  Given the broad diversity of JWT usage and applications, the best
>  combination of types, required claims, values, header parameters, key
>  usages, and issuers to differentiate among different kinds of JWTs
>  will, in general, be application specific.

I get that this is the state we find ourselves in, but it seems like
it's unfortunate. This might be a good time to re-emphasize the
recommendation for explicit types in 3.11.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] AD Review of draft-ietf-oauth-jwt-bcp

[Eric Rescorla]

On Mon, Nov 5, 2018 at 12:39 AM Mike Jones 
wrote:

> Hi Eric.  Thanks again for your review.
> https://github.com/yaronf/I-D/pull/24 is intended to address your review
> comments.  Text changes made to address each of your comments are listed
> below.
>
>
>
> *From:* OAuth  *On Behalf Of * Eric Rescorla
> *Sent:* Monday, August 27, 2018 4:03 AM
> *To:* oauth 
> *Subject:* [OAUTH-WG] AD Review of draft-ietf-oauth-jwt-bcp
>
>
>
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D4649
>
>
> COMMENTS
> S 1.2.
> >   1.2.  Conventions used in this document
> >
> >  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> >  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
> >  "OPTIONAL" in this document are to be interpreted as described in
> >  [RFC2119].
>
> You will want to cite 8174 here.
>
> < The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD",
>
> < "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in
> this document are to be
>
> < interpreted as described in {{RFC2119}}.
>
> ---
>
> > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
>
> > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
>
> > "MAY", and "OPTIONAL" in this document are to be interpreted as
>
> > described in BCP 14 {{RFC2119}} {{RFC8174}} when, and only when, they
>
> > appear in all capitals, as shown here.
>
>
> S 2.6.
> >
> >   2.6.  Substitution Attacks
> >
> >  There are attacks in which one recipient will have a JWT intended
> for
> >  it and attempt to use it at a different recipient that it was not
> >  intended for.  If not caught, these attacks can result in the
>
> I don't understand this attack. Can you go into more detail?
>
> > For instance, if an OAuth 2.0 {{RFC6749}} access token is presented to
> an OAuth 2.0 protected resource
>
> > that it is intended for, that protected resource might attempt to gain
> access to a different
>
> > protected resource by presenting that same access token to the different
> protected resource,
>
> > which the access token is not intended for.
>
> S 3.2.
> >  Therefore, applications MUST only allow the use of cryptographically
> >  current algorithms that meet the security requirements of the
> >  application..  This set will vary over time as new algorithms are
> >  introduced and existing algorithms are deprecated due to discovered
> >  cryptographic weaknesses.  Applications must therefore be designed
> to
> >  enable cryptographic agility.
>
> Is this must normative?
>
> < Applications must therefore be designed to enable cryptographic agility.
>
> ---
>
> > Applications MUST therefore be designed to enable cryptographic agility.
>
>
> S 3.2.
> >  may be no need to apply another layer of cryptographic protections
> to
> >  the JWT.  In such cases, the use of the "none" algorithm can be
> >  perfectly acceptable.  JWTs using "none" are often used in
> >  application contexts in which the content is optionally signed; then
> >  the URL-safe claims representation and processing can be the same in
> >  both the signed and unsigned cases.
>
> I think you probably need to have a clearer "don't use none by
> default" statement here.
>
> > The "none" algorithm should only be used when the JWT is
> cryptographically protected by other means.
>

Is there a reason this isn't a MUST?


S 3.4.
>
> >  ECDH-ES ephemeral public key (epk) inputs should be validated
> >  according to the recipient's chosen elliptic curve.  For the NIST
> >  prime-order curves P-256, P-384 and P-521, validation MUST be
> >  performed according to Section 5.6.2.3.4 "ECC Partial Public-Key
> >  Validation Routine" of NIST Special Publication 800-56A revision 3
> >  [nist-sp-800-56a-r3].
>
> Is there an X25519 specification for JWE? If so, you should probably
> specify the appropriate checks.
>
> > Likewise, if the "X25519" or "X448" {{RFC8037}} algorithms are used,
>
> > then the values MUST be valida

[OAUTH-WG] AD Review of draft-ietf-oauth-jwt-bcp

[Eric Rescorla]

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4649


COMMENTS
S 1.2.
>   1.2.  Conventions used in this document
>
>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>  "OPTIONAL" in this document are to be interpreted as described in
>  [RFC2119].

You will want to cite 8174 here.


S 2.6.
>
>   2.6.  Substitution Attacks
>
>  There are attacks in which one recipient will have a JWT intended for
>  it and attempt to use it at a different recipient that it was not
>  intended for.  If not caught, these attacks can result in the

I don't understand this attack. Can you go into more detail?


S 3.2.
>  Therefore, applications MUST only allow the use of cryptographically
>  current algorithms that meet the security requirements of the
>  application.  This set will vary over time as new algorithms are
>  introduced and existing algorithms are deprecated due to discovered
>  cryptographic weaknesses.  Applications must therefore be designed to
>  enable cryptographic agility.

Is this must normative?


S 3.2.
>  may be no need to apply another layer of cryptographic protections to
>  the JWT.  In such cases, the use of the "none" algorithm can be
>  perfectly acceptable.  JWTs using "none" are often used in
>  application contexts in which the content is optionally signed; then
>  the URL-safe claims representation and processing can be the same in
>  both the signed and unsigned cases.

I think you probably need to have a clearer "don't use none by
default" statement here.


S 3.4.
>  ECDH-ES ephemeral public key (epk) inputs should be validated
>  according to the recipient's chosen elliptic curve.  For the NIST
>  prime-order curves P-256, P-384 and P-521, validation MUST be
>  performed according to Section 5.6.2.3.4 "ECC Partial Public-Key
>  Validation Routine" of NIST Special Publication 800-56A revision 3
>  [nist-sp-800-56a-r3].

Is there an X25519 specification for JWE? If so, you should probably
specify the appropriate checks.


S 3.5.
>   3.5.  Ensure Cryptographic Keys have Sufficient Entropy
>
>  The Key Entropy and Random Values advice in Section 10.1 of [RFC7515]
>  and the Password Considerations in Section 8.8 of [RFC7518] MUST be
>  followed.  In particular, human-memorizable passwords MUST NOT be
>  directly used as the key to a keyed-MAC algorithm such as "HS256".

If you can't use them "directly" than how should you use them? Do you
want to say anything about password hashing (argon, etc.)?


S 3.12.
> of JWTs.
>
>  Given the broad diversity of JWT usage and applications, the best
>  combination of types, required claims, values, header parameters, key
>  usages, and issuers to differentiate among different kinds of JWTs
>  will, in general, be application specific.

I get that this is the state we find ourselves in, but it seems like
it's unfortunate. This might be a good time to re-emphasize the
recommendation for explicit types in 3.11.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt

[Eric Rescorla]

This text is fine. I have issued IETF-LC.

On Mon, Jun 4, 2018 at 1:45 PM, Brian Campbell 
wrote:

> Thanks Eric, I've added text in the just submitted -14 saying that only
> the two ends of the chain are to be considered in access control policy
> decisions.
>
> diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-14
>
> htmlized:
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-14
>
>
> On Fri, Jun 1, 2018 at 10:02 PM, Eric Rescorla  wrote:
>
>> OK, well, it seems like it ought to say that that generator of the token
>> can expect that the RP will apply an access control policy that s the union
>> of the capabilities of the two ends of the chain -- and that while it might
>> be less it won't be more.
>>
>> -Ekr
>>
>>
>> On Fri, Jun 1, 2018 at 3:15 PM, Brian Campbell <
>> bcampb...@pingidentity.com> wrote:
>>
>>> I suspect that the vast majority of time C's permissions won't matter at
>>> all. But I do think there are legitimate cases where they might be
>>> considered in the policy decision. One general example I can think of is a
>>> customer service rep or administrator taking override type corrective
>>> action on an end-user's account or transaction information (A is the
>>> end-user and C is the customer service rep) that the user on their own
>>> wouldn't have permission to change.
>>>
>>> On Fri, Jun 1, 2018 at 3:47 PM, Eric Rescorla  wrote:
>>>
>>>> That would go a long way, I think. Do you think that C's permissions
>>>> matter at all? So, say that the resource is accessible to C but not A?
>>>>
>>>> -Ekr
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Jun 1, 2018 at 11:47 AM, Brian Campbell <
>>>> bcampb...@pingidentity.com> wrote:
>>>>
>>>>> Hi Eric,
>>>>>
>>>>> Apologies for my somewhat slow response. I've honestly been unsure of
>>>>> how else to try and address the comment/question. But will continue
>>>>> trying...
>>>>>
>>>>> My expectation would be that access control decisions would be made
>>>>> based on the subject of the token itself or on the current actor. And 
>>>>> maybe
>>>>> a combination of both in some situations (like, for example, the actor is
>>>>> an administrator and the token allows admin level access to the stuff the
>>>>> token subject would normally have access to).  However, I don't believe
>>>>> that nested prior actors would or should be considered in access control
>>>>> decisions. The nesting is more just to express what has happened for
>>>>> auditing or tracking or the like. To be honest, the nesting was added in
>>>>> the draft largely because the structure naturally and easily allowed for 
>>>>> it
>>>>> and it seemed like it might be useful information to convey in some cases.
>>>>>
>>>>> So in that A->B->C case (the claims of such a token would, I think,
>>>>> look like the JSON below), B *is not* giving C his authority. B is
>>>>> just noted in the token as having been involved previously.  While A is
>>>>> identified as the subject of the token and C is the current actor.
>>>>>
>>>>> {
>>>>>   "aud":"... ,"iss":... , "exp":..., etc. etc. ...
>>>>>   "sub":"A",
>>>>>   "act":
>>>>>   {
>>>>> "sub":"C",
>>>>> "act":
>>>>> {
>>>>>   "sub":"B"
>>>>> }
>>>>>   }
>>>>> }
>>>>>
>>>>>
>>>>> Would some text explicitly saying that only the token subject (top
>>>>> level sub and claims) and the party identified by the outermost "act" 
>>>>> claim
>>>>> (the current actor) are to be considered in access control decisions
>>>>> address your concern?
>>>>>
>>>>>
>>>>> On Tue, May 29, 2018 at 4:19 PM, Eric Rescorla  wrote:
>>>>>
>>>>>> Hi Brian,
>>>>>>
>>>>>> To be clear, I'm not opposing Delegation. My concern here is that we
>>>>>> have a chain of signed ass

Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt

[Eric Rescorla]

OK, well, it seems like it ought to say that that generator of the token
can expect that the RP will apply an access control policy that s the union
of the capabilities of the two ends of the chain -- and that while it might
be less it won't be more.

-Ekr


On Fri, Jun 1, 2018 at 3:15 PM, Brian Campbell 
wrote:

> I suspect that the vast majority of time C's permissions won't matter at
> all. But I do think there are legitimate cases where they might be
> considered in the policy decision. One general example I can think of is a
> customer service rep or administrator taking override type corrective
> action on an end-user's account or transaction information (A is the
> end-user and C is the customer service rep) that the user on their own
> wouldn't have permission to change.
>
> On Fri, Jun 1, 2018 at 3:47 PM, Eric Rescorla  wrote:
>
>> That would go a long way, I think. Do you think that C's permissions
>> matter at all? So, say that the resource is accessible to C but not A?
>>
>> -Ekr
>>
>>
>>
>>
>> On Fri, Jun 1, 2018 at 11:47 AM, Brian Campbell <
>> bcampb...@pingidentity.com> wrote:
>>
>>> Hi Eric,
>>>
>>> Apologies for my somewhat slow response. I've honestly been unsure of
>>> how else to try and address the comment/question. But will continue
>>> trying...
>>>
>>> My expectation would be that access control decisions would be made
>>> based on the subject of the token itself or on the current actor. And maybe
>>> a combination of both in some situations (like, for example, the actor is
>>> an administrator and the token allows admin level access to the stuff the
>>> token subject would normally have access to).  However, I don't believe
>>> that nested prior actors would or should be considered in access control
>>> decisions. The nesting is more just to express what has happened for
>>> auditing or tracking or the like. To be honest, the nesting was added in
>>> the draft largely because the structure naturally and easily allowed for it
>>> and it seemed like it might be useful information to convey in some cases.
>>>
>>> So in that A->B->C case (the claims of such a token would, I think, look
>>> like the JSON below), B *is not* giving C his authority. B is just
>>> noted in the token as having been involved previously.  While A is
>>> identified as the subject of the token and C is the current actor.
>>>
>>> {
>>>   "aud":"... ,"iss":... , "exp":..., etc. etc. ...
>>>   "sub":"A",
>>>   "act":
>>>   {
>>> "sub":"C",
>>> "act":
>>> {
>>>   "sub":"B"
>>> }
>>>   }
>>> }
>>>
>>>
>>> Would some text explicitly saying that only the token subject (top level
>>> sub and claims) and the party identified by the outermost "act" claim (the
>>> current actor) are to be considered in access control decisions address
>>> your concern?
>>>
>>>
>>> On Tue, May 29, 2018 at 4:19 PM, Eric Rescorla  wrote:
>>>
>>>> Hi Brian,
>>>>
>>>> To be clear, I'm not opposing Delegation. My concern here is that we
>>>> have a chain of signed assertions and I'm trying to understand how I as a
>>>> consumer of those assertions am supposed to evaluate it.
>>>>
>>>> I don't think it's sufficient to just say that that the access control
>>>> rules are local policy, because then the entity generating the signature
>>>> has no way of knowing how its signature will be used.
>>>>
>>>> To go back to the case I gave in my initial e-mail, say we have a chain
>>>> A->B->C and a resource that A and C could ordinarily not access, but B can.
>>>> If C has this delegation, can C access the resource? I.e., is B giving C
>>>> his authority or just passing on A's authority? It seems pretty important
>>>> for B to know that before he gives the token to C.
>>>>
>>>> -Ekr
>>>>
>>>>
>>>> On Thu, May 17, 2018 at 11:06 AM, Brian Campbell <
>>>> bcampb...@pingidentity.com> wrote:
>>>>
>>>>> Delegation has been in the document since its inception and throughout
>>>>> the three and a half years as a working group document.
>>>>>
>>>&g

Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt

[Eric Rescorla]

That would go a long way, I think. Do you think that C's permissions matter
at all? So, say that the resource is accessible to C but not A?

-Ekr




On Fri, Jun 1, 2018 at 11:47 AM, Brian Campbell 
wrote:

> Hi Eric,
>
> Apologies for my somewhat slow response. I've honestly been unsure of how
> else to try and address the comment/question. But will continue trying...
>
> My expectation would be that access control decisions would be made based
> on the subject of the token itself or on the current actor. And maybe a
> combination of both in some situations (like, for example, the actor is an
> administrator and the token allows admin level access to the stuff the
> token subject would normally have access to).  However, I don't believe
> that nested prior actors would or should be considered in access control
> decisions. The nesting is more just to express what has happened for
> auditing or tracking or the like. To be honest, the nesting was added in
> the draft largely because the structure naturally and easily allowed for it
> and it seemed like it might be useful information to convey in some cases.
>
> So in that A->B->C case (the claims of such a token would, I think, look
> like the JSON below), B *is not* giving C his authority. B is just noted
> in the token as having been involved previously.  While A is identified as
> the subject of the token and C is the current actor.
>
> {
>   "aud":"... ,"iss":... , "exp":..., etc. etc. ...
>   "sub":"A",
>   "act":
>   {
> "sub":"C",
> "act":
> {
>   "sub":"B"
> }
>   }
> }
>
>
> Would some text explicitly saying that only the token subject (top level
> sub and claims) and the party identified by the outermost "act" claim (the
> current actor) are to be considered in access control decisions address
> your concern?
>
>
> On Tue, May 29, 2018 at 4:19 PM, Eric Rescorla  wrote:
>
>> Hi Brian,
>>
>> To be clear, I'm not opposing Delegation. My concern here is that we have
>> a chain of signed assertions and I'm trying to understand how I as a
>> consumer of those assertions am supposed to evaluate it.
>>
>> I don't think it's sufficient to just say that that the access control
>> rules are local policy, because then the entity generating the signature
>> has no way of knowing how its signature will be used.
>>
>> To go back to the case I gave in my initial e-mail, say we have a chain
>> A->B->C and a resource that A and C could ordinarily not access, but B can.
>> If C has this delegation, can C access the resource? I.e., is B giving C
>> his authority or just passing on A's authority? It seems pretty important
>> for B to know that before he gives the token to C.
>>
>> -Ekr
>>
>>
>> On Thu, May 17, 2018 at 11:06 AM, Brian Campbell <
>> bcampb...@pingidentity.com> wrote:
>>
>>> Delegation has been in the document since its inception and throughout
>>> the three and a half years as a working group document.
>>>
>>> From a process point of view, the document is now in AD Evaluation. I
>>> worked through a number of questions and clarifications with Eric (said
>>> AD), however he raised the particular questions that started this thread on
>>> the WG list. And I responded with an attempt at addressing those questions.
>>> That was about a month ago.
>>>
>>> Eric, was my explanation helpful in clarify anything for you? Is there
>>> some text that you'd like to see added? Something else? I'm unsure how to
>>> proceed but would like to move things forward.
>>>
>>>
>>> On Thu, May 17, 2018 at 8:03 AM, Bill Burke  wrote:
>>>
>>>> This is an honest question: How important is the actor stuff to the
>>>> players involved?  Are people going to use it?  IMO, its an edge case
>>>> and I think more important areas, like external token exchange (realm
>>>> to realm, domain to domain) are being neglected.  I'm quite unfamiliar
>>>> how consensus is reached in this WG or the IETF, so I hope I'm not
>>>> sounding rude.  Just trying to provide some constructive feedback.
>>>>
>>>>
>>>>
>>>> On Thu, May 17, 2018 at 9:26 AM, Mike Jones <
>>>> michael.jo...@microsoft.com> wrote:
>>>> > Moving the actor claim to a separate specification would only make
>>>> things more complicated for developers.  There already ple

Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt

[Eric Rescorla]

uch. Such a claim cannot be verified.
>> >>> A RP could copy and paste that claim in an audit log. No standard
>> >>> action related to the content of such a claim can be specified in the
>> >>> spec. If the content of a "claimed actor" is used by the RP, it
>> >>> should be only used as an hint and thus be subject to other
>> >>> verifications which are not specified in this specification.
>> >>>
>> >>> Denis
>> >>>
>> >>> Eric, I realize you weren't particularly impressed by my prior
>> >>> statements about the actor claim but, for lack of knowing what else
>> >>> to say, I'm going to kind of repeat what I said about it over in the
>> >>> Phabricator tool and add a little color.
>> >>>
>> >>> The actor claim is intended as a way to express that delegation has
>> >>> happened and identify the entities involved. Access control or other
>> >>> decisions based on it are at the discretion of the consumer of the
>> >>> token based on whatever policy might be in place.
>> >>>
>> >>> There are JWT claims that have concise processing rules with respect
>> >>> to whether or not the JWT can be accepted as valid. Some examples are
>> "aud"
>> >>> (Audience), "exp" (Expiration Time), and "nbf" (Not Before) from RFC
>> 7519.
>> >>> E.g. if the token is expired or was intended for someone or something
>> >>> else, reject it.
>> >>>
>> >>> And there are JWT claims that appropriately don't specify such
>> >>> processing rules and are solely statements of fact or circumstance.
>> >>> Also from RFC 7519, the "sub" (Subject) and "iat" (Issued At) claims
>> are good examples of such.
>> >>> There might be application or policy specific rules applied to the
>> >>> content of those kinds of claims (e.g. only subjects from a
>> >>> particular organization are able to access tenant specific data or,
>> >>> less realistic but still possible, disallow access for tokens issued
>> >>> outside of regular business
>> >>> hours) but that's all outside the scope of a specification's
>> >>> definition of the claim.
>> >>>
>> >>> The actor claim falls into the latter category. It's a way for the
>> >>> issuer of the token to tell the consumer of the token what is going
>> >>> on. But any action to take (or not) based on that information is at
>> >>> the discretion of the token consumer. I honestly don't know it could
>> >>> be anything more. And don't think it should be.
>> >>>
>> >>> There are two main expected uses of the actor claim (that I'm aware
>> >>> of
>> >>> anyway) that describing here might help. Maybe. One is a human to
>> >>> human delegation case like a customer service rep doing something on
>> >>> behalf of an end user. The subject would be that user and the actor
>> >>> would be the customer service rep. And there wouldn't be any chaining
>> >>> or nesting of the actor. The other case is so called service chaining
>> >>> where a system might exchange a token it receives for a new token
>> >>> that it can use to call a downstream service. And that service in
>> >>> turn might do another exchange to get a new token suitable to call
>> >>> yet another downstream service. And again and so on and turtles all
>> >>> the way. I'm not necessarily endorsing that level of granularity in
>> >>> chaining but it's bound to happen somewhere/sometime. The nested
>> >>> actor claim is able to express that all that has happened with the
>> >>> top level or outermost one being the system currently using the token
>> >>> and prior systems being nested.. What actually gets done with that
>> >>> information is up to the respective systems involved. There might be
>> >>> policy about what system is allowed to call what other system that is
>> >>> enforced. Or maybe the info is just written to an audit log
>> >>> somewhere. Or something else. I don't know. But whatever it is
>> application/deployment/policy dependent and not specifiable by a spec.
>> >>>
>> >>>
>> >>>
>> >>>
>

Re: [OAUTH-WG] Follow up on draft-ietf-oauth-device-flow-08

[Eric Rescorla]

LGTM. Issuing LC.

On Mon, Apr 23, 2018 at 12:20 PM, Mike Jones 
wrote:

> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-09  Sections 5.2
> and 5.3 contain the confused deputy attack updates described in John’s
> response during London.
>
>
>
> -- Mike
>
>
>
> *From:* Eric Rescorla 
> *Sent:* Friday, April 13, 2018 7:37 PM
> *To:* Mike Jones 
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Follow up on draft-ietf-oauth-device-flow-08
>
>
>
> Thanks for the quick followup. I will take a look at the next version
>
>
>
> -Ekr
>
>
>
>
>
> On Fri, Apr 13, 2018 at 6:06 PM, Mike Jones 
> wrote:
>
> We still need to add the text addressing the points described in John
> Bradley’s reply to you sent while in London.
>
>
>
>-- Mike
>
>
>
> *From:* OAuth  *On Behalf Of *Eric Rescorla
> *Sent:* Friday, April 13, 2018 6:00 PM
> *To:* oauth@ietf.org
> *Subject:* [OAUTH-WG] Follow up on draft-ietf-oauth-device-flow-08
>
>
>
> Hi folks,
>
>
>
> I just looked at the -08 diffs and I see a new section on brute forcing
> the token
>
> but not describing the confused deputy attack. Did I miss something, or
> were you
>
> still planning to add more text?
>
>
>
> Thanks
>
> -Ekr
>
>
>
>
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Follow up on draft-ietf-oauth-device-flow-08

[Eric Rescorla]

Thanks for the quick followup. I will take a look at the next version

-Ekr


On Fri, Apr 13, 2018 at 6:06 PM, Mike Jones <michael.jo...@microsoft.com>
wrote:

> We still need to add the text addressing the points described in John
> Bradley’s reply to you sent while in London.
>
>
>
>-- Mike
>
>
>
> *From:* OAuth <oauth-boun...@ietf.org> *On Behalf Of * Eric Rescorla
> *Sent:* Friday, April 13, 2018 6:00 PM
> *To:* oauth@ietf.org
> *Subject:* [OAUTH-WG] Follow up on draft-ietf-oauth-device-flow-08
>
>
>
> Hi folks,
>
>
>
> I just looked at the -08 diffs and I see a new section on brute forcing
> the token
>
> but not describing the confused deputy attack. Did I miss something, or
> were you
>
> still planning to add more text?
>
>
>
> Thanks
>
> -Ekr
>
>
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Follow up on draft-ietf-oauth-device-flow-08

[Eric Rescorla]

Hi folks,

I just looked at the -08 diffs and I see a new section on brute forcing the
token
but not describing the confused deputy attack. Did I miss something, or
were you
still planning to add more text?

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

[OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt

[Eric Rescorla]

Hi folks,

I've gone over draft-ietf-oauth-token-exchange-12 and things seem
generally OK. I do still have one remaining concern, which is about
the actor claim. Specifically, what is the RP supposed to do when they
encounter it? This seems kind of underspecified.

In particular:

1. What facts am I supposed to know here? Merely that everyone in
   the chain signed off on the next person in the chain acting as them?

2. Am I just supposed to pretend that the person presenting the token
   is the identity at the top of the chain? Say I have the
   delegation A -> B -> C, and there is some resource which
   B can access but A and C cannot, should I give access?

I think the first question definitely needs an answer. The second
question I guess we could make not answer, but it's pretty hard
to know how to make a system with this left open.

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

[OAUTH-WG] AD Review: draft-ietf-oauth-token-exchange-09

[Eric Rescorla]

Full-featured review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4278

As noted in inline comments, some additional words about the security model
in which this document is embedded seem like they are needed. In
particular, it's pretty unclear to me what checks the STS is supposed to do
on a given request to determine whether to fulfill it. Where is that
documented?

*INLINE COMMENTS*
View Inline 
draft-ietf-oauth-token-exchange.txt:129
securing access to HTTP and RESTful resources but do not provide
everything necessary to facilitate token exchange interactions.

Can you say a bit more about what is missing here?

View Inline 
draft-ietf-oauth-token-exchange.txt:265
REQUIRED. The value "urn:ietf:params:oauth:grant-type:token-
exchange" indicates that a token exchange is being performed.

I note that S 4.5. says that the grant_type is "defined by the
authorization server" but that's not the case here, right?

View Inline 
draft-ietf-oauth-token-exchange.txt:268
resource
OPTIONAL. Indicates the physical location of the target service
or resource where the client intends to use the requested security

Do you actually mean "physical" here? Presumably if it's a URI it's most
likely a network address. I would take "physical" to mean "geographic"

View Inline 
draft-ietf-oauth-token-exchange.txt:304
target services with a mix of logical names and physical
locations.

But it seems you can only specify one of each, right?

View Inline 
draft-ietf-oauth-token-exchange.txt:310
security token in the context of the service or resource where the
token will be used.

It's not clear to me where these values would come from. Can you expand on
this?

View Inline 
draft-ietf-oauth-token-exchange.txt:341
REQUIRED when the "actor_token" parameter is present in the
request but MUST NOT be included otherwise.

It's not entirely clear to me from this text how these tokens authenticate
the request. It's clear if they are bearer tokens, but if they are some
sort of token over a public key, then how does that work.

View Inline 
draft-ietf-oauth-token-exchange.txt:587
2.0 [OASIS.saml-core-2.0-os] assertion, respectively. Other URIs to
indicate other token types MAY be used.

This feels like it would be better as some kind of list (maybe bulleted)?

View Inline 
draft-ietf-oauth-token-exchange.txt:666
it as the current actor and that can be used at
https://backend.example.com.

Where can I find the definitions of "iss" and "sub"?

View Inline 
draft-ietf-oauth-token-exchange.txt:689
response, "act" has the same semantics and format as the claim of the
same name.

It's not entirely clear to me how I'm supposed to evaluate these from an
access control perspective.

Is the assumption here that the entity producing the JWT has ensured the
correct chain of issuers and subs?

Is it the RP's job to evaluate whether each entity in the chain could have
performed the action?

View Inline 
draft-ietf-oauth-token-exchange.txt:755
claims such as "exp", "nbf", and "aud" are not meaningful when used
within a "may_act" claim, and therefore should not be used.

I'm having a hard time understanding this claim. Can you provide an example
to me (in email is fine, it doesn't need to be in the draft) of how it
would be used?

View Inline 
draft-ietf-oauth-token-exchange.txt:1273
produced under the chairmanship of Hannes Tschofenig and Derek Atkins
with Kathleen Moriarty and Stephen Farrell serving as Security Area
Directors. The following individuals contributed ideas, feedback,

You may want to update this

*REPOSITORY*
rIETFREVIEW ietf-review

*REVISION DETAIL*
https://mozphab-ietf.devsvcdev.mozaws.net/D4278

*EMAIL PREFERENCES*
https://mozphab-ietf.devsvcdev.mozaws.net/settings/panel/emailpreferences/

*To: *ekr-moz, ekr
*Cc: *ekr
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] AD Review: draft-ietf-oauth-discovery-06

[Eric Rescorla]

Hi Mike,

These changes look good. I have pushed the last call button.

-Ekr






On Mon, Sep 11, 2017 at 12:35 PM, Mike Jones <michael.jo...@microsoft.com>
wrote:

> Eric, I believe that https://tools.ietf.org/html/
> draft-ietf-oauth-discovery-07 addresses all your comments.  Thanks for
> them again.
>
> If you agree, can you please progress the document to the next step?
>
> Thanks,
> -- Mike
>
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
> Sent: Thursday, September 7, 2017 2:25 PM
> To: Eric Rescorla <e...@rtfm.com>; oauth@ietf.org
> Subject: Re: [OAUTH-WG] AD Review: draft-ietf-oauth-discovery-06
>
> Draft -07 https://tools.ietf.org/html/draft-ietf-oauth-discovery-07
> contains these proposed resolutions.  The only change is that in places
> where I'd previously proposed to say "If omitted, these authentication
> methods cannot be used" I now say "This metadata entry MUST be present if
> either of these authentication methods are specified in the
> "{token,revocation,introspection}_endpoint_auth_methods_supported"
> entry.  No default algorithms are implied if this entry is omitted."
>
> I made the change because saying that they cannot be used isn't actually
> correct.  This information could always have been communicated out-of-band
> to the metadata.
>
>     -- Mike
>
> -Original Message-
> From: Mike Jones
> Sent: Tuesday, September 5, 2017 4:12 PM
> To: 'Eric Rescorla' <e...@rtfm.com>; oauth@ietf.org
> Subject: RE: [OAUTH-WG] AD Review: draft-ietf-oauth-discovery-06
>
> Thanks for your useful review, Eric.  Proposed resolutions to all comments
> are inline prefixed by "Mike>".
>
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Eric Rescorla
> Sent: Sunday, September 3, 2017 3:26 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] AD Review: draft-ietf-oauth-discovery-06
>
> Hi folks,
>
> Note: the original of this review is on Phabricator at:
>
>   https://mozphab-ietf.devsvcdev.mozaws.net/D7
>
> If you want to see comments in context, you can go there. Also, you can
> create an account and respond inline if you like.
> If you elect to, let me know if you run into problems.
>
> -Ekr
>
>
> I have marked a number of places where it seems like you either need
> defaults or need to indicate what the semantics are if missing
>
>
>This metadata can either be communicated in a self-asserted fashion
>or as a set of signed metadata values represented as claims in a JSON I
> assume "self-asserted" in this case means "asserted by the server origin
> via HTTPS"
>
> Mike> Thanks - I will use this language.
>
> Line 222
>   authentication methods.  Servers SHOULD support "RS256".  The
>   value "none" MUST NOT be used.
> What's the default if omitted?
>
> Mike> I will add "If omitted, these authentication methods cannot be used."
>
> Line 235
>   represented as a JSON array of BCP47 [RFC5646] language tag
>   values.
> What's the default if omitted?
>
> Mike> There is no default.  I will add "If omitted, the set of supported
> languages and scripts is unspecified."
>
> Line 267
>   "OAuth Token Endpoint Authentication Methods" registry
>   [IANA.OAuth.Parameters].
> What's the default if omitted?
>
> Mike> I will add client_secret_basic as the default - just like it already
> was for token_endpoint_auth_methods_supported.
>
> Line 275
>   "client_secret_jwt" authentication methods.  The value "none" MUST
>   NOT be used.
> What's the default if omitted?
>
> Mike> I will add "If omitted, these authentication methods cannot be used."
>
> Line 288
>   Access Token Types" registry [IANA.OAuth.Parameters].  (These
>   values are and will remain distinct, due to Section 7.2.) What's the
> default if omitted?
>
> Mike> There is no obvious default.  Therefore, I will add "If omitted, the
> set of supported authentication methods MUST be determined by other means."
>
> Line 296
>   "client_secret_jwt" authentication methods.  The value "none" MUST
>   NOT be used.
> What's the default if omitted?
>
> Mike> I will add "If omitted, these authentication methods cannot be used."
>
> Line 304
>   challenge method values are those registered in the IANA "PKCE
>   Code Challenge Methods" registry [IANA.OAuth.Parameters].
> 

[OAUTH-WG] AD Review: draft-ietf-oauth-discovery-06

[Eric Rescorla]

Hi folks,

Note: the original of this review is on Phabricator at:

  https://mozphab-ietf.devsvcdev.mozaws.net/D7

If you want to see comments in context, you can go there. Also,
you can create an account and respond inline if you like.
If you elect to, let me know if you run into problems.

-Ekr


I have marked a number of places where it seems like you either need
defaults or need to indicate what the semantics are if missing


   This metadata can either be communicated in a self-asserted fashion
   or as a set of signed metadata values represented as claims in a JSON
I assume "self-asserted" in this case means "asserted by the server origin
via HTTPS"


Line 222
  authentication methods.  Servers SHOULD support "RS256".  The
  value "none" MUST NOT be used.
What's the default if omitted?


Line 235
  represented as a JSON array of BCP47 [RFC5646] language tag
  values.
What's the default if omitted?


Line 267
  "OAuth Token Endpoint Authentication Methods" registry
  [IANA.OAuth.Parameters].
What's the default if omitted?


Line 275
  "client_secret_jwt" authentication methods.  The value "none" MUST
  NOT be used.
What's the default if omitted?


Line 288
  Access Token Types" registry [IANA.OAuth.Parameters].  (These
  values are and will remain distinct, due to Section 7.2.)
What's the default if omitted?


Line 296
  "client_secret_jwt" authentication methods.  The value "none" MUST
  NOT be used.
What's the default if omitted?


Line 304
  challenge method values are those registered in the IANA "PKCE
  Code Challenge Methods" registry [IANA.OAuth.Parameters].
What's the default if omitted?

Line 343
   MUST be registered in the IANA "Well-Known URIs" registry
   [IANA.well-known].
IMPORTANT: Shouldn't this be required to be HTTPS

Line 500
   client MUST perform a TLS/SSL server certificate check, per RFC 6125
   [RFC6125].  Implementation security considerations can be found in
   Recommendations for Secure Use of TLS and DTLS [BCP195].
Hmm I'm unsure about whether this should be a citation to 2818. Is the
general feeling that 6125 superceded 2818?


Line 564
   The following registration procedure is used for the registry
   established by this specification.
This section seems like it needs RFC2119 language


Line 568
   Values are registered on a Specification Required [RFC5226] basis
   after a two-week review period on the oauth-ext-rev...@ietf.org
   mailing list, on the advice of one or more Designated Experts.
What happens if you don't do anything within two weeks.


Line 756
   o  Change Controller: IESG
   o  Specification Document(s): Section 2 of [[ this specification ]]
Extra whitespace.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Eric Rescorla's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
draft-ietf-oauth-native-apps-11: 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-native-apps/



--
COMMENT:
--

Document: draft-ietf-oauth-native-apps-11.txt

S 7.
   To fully support this best practice, authorization servers MUST
   support the following three redirect URI options.  Native apps MAY
   use whichever redirect option suits their needs best, taking into
   account platform specific implementation details.

It's not entirely clear from this text what "support" means. Would
just echoing whatever redirect URI the client provided count as
support?


S 7.2.

   App-claimed HTTPS redirect URIs have some advantages in that the
   identity of the destination app is guaranteed by the operating
   system.  For this reason, they SHOULD be used in preference to the
   other redirect options for native apps where possible.

You should probably be clearer on who this guarantee is provided to.
And I assume this SHOULD is directed to app authors?

   Claimed HTTPS redirect URIs function as normal HTTPS redirects from
   the perspective of the authorization server, though as stated in
   Section 8.4, it is REQUIRED that the authorization server is able to
   distinguish between public native app clients that use app-claimed
   HTTPS redirect URIs and confidential web clients.

S 8.4 doesn't seem clear on how one makes this distinction. Is
it just a matter of remembering what the app author told you?


S 8.1.
   As most forms of inter-app URI-based communication send data over
   insecure local channels, eavesdropping and interception of the
   authorization response is a risk for native apps.  App-claimed HTTPS
   redirects are hardened against this type of attack due to the
   presence of the URI authority, but they are still public clients and
   the URI is still transmitted over local channels with unknown
   security properties.

I'm probably missing something, but I'm not sure what this last
sentence means. Is the channel here the one that kicks off the
native app with the HTTPS URI as the target?


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