[OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-amr-values-07: (with COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-oauth-amr-values-07: 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-amr-values/ -- COMMENT: -- Thanks for clarifying that amr represents classes of auth methods and not (always) individual methods, that all makes more sense now;-) I think you might usefully add the phrase "classes of" (or similar) to the draft in a few places to help folks understand that, in particular, I spotted two places where I think something like that'd be good: 1. in the definition, I'd suggest: OLD: amr OPTIONAL. Authentication Methods References. JSON array of strings that are identifiers for authentication methods used in the authentication. NEW: amr OPTIONAL. Authentication Methods References. JSON array of strings that are identifiers for classes of authentication methods used in the authentication. 2. In the IANA considerations and DE guidance, maybe make the name of the new registry reflect that these are classes, in case someone gets confused only having looked at the IANA pages without reading the RFC, and perhaps point the DE guidance back to the top bit where you explain this stuff and add "classes of" in a few places in the template to save the DEs having to explain that over and over to people who just copy templates. Thanks, S. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
On 07/03/17 17:17, Mike Jones wrote: > You're right, Stephen. Re-reading the spec, it doesn't say that, and > it should. Sometimes it takes someone giving a spec a fresh read to > uncover things that the authors understood and intended but failed to > be captured in the text. This is such a case - so thanks. > > I'll add this information, which is necessary to understand the > intent, and then republish. Ah good, that explains the disconnect. Cheers, S. > > -- Mike > > -Original Message- From: Stephen Farrell > [mailto:stephen.farr...@cs.tcd.ie] Sent: Monday, March 6, 2017 2:39 > PM To: Mike Jones <michael.jo...@microsoft.com>; Anthony Nadalin > <tony...@microsoft.com>; joel jaeggli <joe...@bogus.com>; The IESG > <i...@ietf.org> Cc: oauth-cha...@ietf.org; > draft-ietf-oauth-amr-val...@ietf.org; oauth@ietf.org Subject: Re: > [OAUTH-WG] Stephen Farrell's Discuss on > draft-ietf-oauth-amr-values-05: (with DISCUSS) > > > Hi Mike, > > On 06/03/17 22:34, Mike Jones wrote: >> Thanks for the reply, Stephen. I'll try to find better >> interop-producing references where possible. >> >> >> In some cases, however, the values are intentionally intended to >> provide an identifier for a family of closely-related methods, such >> as "otp", which covers both time-based and HMAC-based OTPs. > > Hmm. I don't recall text saying that in the draft, but it's possible > that I missed it - can you point me at that? > > I do agree that if the semantics here were "some otp was used" then > it would not be necessary to specify exactly which OTP scheme was > used. But that wasn't how I read what this spec was doing. (Again, > that could be me getting the wrong end of the stick.) > > S. > > >> Many relying parties will be content to know that an OTP has been >> used in addition to a password. The distinction between which kind >> of OTP was used is not useful to them. Thus, there's a single >> identifier that can be satisfied in two or more nearly equivalent >> ways. I consider this to be a feature - not a bug. >> >> >> >> Similarly, there's a whole range of nuances between different >> fingerprint matching algorithms. They differ in false positive and >> false negative rates over different population samples and also >> differ based on the kind and model of fingerprint sensor used. >> Like the OTP case, many RPs will be content to know that a >> fingerprint match mas made, without delving into and >> differentiating based on every aspect of the implementation of >> fingerprint capture and match. Those that want more precision than >> this can always define new "amr" values. But "fpt" is fine as is >> for what I believe will be the 90+% case. >> >> >> >> Ultimately, the RP is depending upon the Identity Provider to do >> reasonable things. If it didn't trust the IdP to do so, it has no >> business using it. The "amr" value lets the IdP signal to the RP >> additional information about what it did, for the cases in which >> that information is useful to the RP. >> >> >> >> Reducing this to the point of absurdity, the RP would almost never >> care about the make, model, and serial number of the fingerprint >> reader or OTP. Values could be defined to provide that >> granularity. But making those fine-grained distinctions are not >> useful in practice. >> >> >> >> Please consider the existing definitions in light of that reductio >> ad absurdum. The existing values only make distinctions that are >> known to be useful to RPs. Slicing things more finely than would >> be used in practice actually hurts interop, rather than helping it, >> because it would force all RPs to recognize that several or many >> different values actually mean the same thing to them. >> >> >> >> -- Mike >> >> >> >> -Original Message- From: Stephen Farrell >> [mailto:stephen.farr...@cs.tcd.ie] Sent: Monday, March 6, 2017 2:10 >> PM To: Mike Jones <michael.jo...@microsoft.com>; Anthony Nadalin >> <tony...@microsoft.com>; joel jaeggli <joe...@bogus.com>; The IESG >> <i...@ietf.org> Cc: oauth-cha...@ietf.org; >> draft-ietf-oauth-amr-val...@ietf.org; oauth@ietf.org Subject: Re: >> [OAUTH-WG] Stephen Farrell's Discuss on >> draft-ietf-oauth-amr-values-05: (with DISCUSS) >> >> >> >> >> >> Hi Mike, >> >> >> >> Apologies - I updated the
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Hi Mike, On 06/03/17 22:34, Mike Jones wrote: > Thanks for the reply, Stephen. I'll try to find better > interop-producing references where possible. > > > In some cases, however, the values are intentionally intended to > provide an identifier for a family of closely-related methods, such > as "otp", which covers both time-based and HMAC-based OTPs. Hmm. I don't recall text saying that in the draft, but it's possible that I missed it - can you point me at that? I do agree that if the semantics here were "some otp was used" then it would not be necessary to specify exactly which OTP scheme was used. But that wasn't how I read what this spec was doing. (Again, that could be me getting the wrong end of the stick.) S. > Many > relying parties will be content to know that an OTP has been used in > addition to a password. The distinction between which kind of OTP > was used is not useful to them. Thus, there's a single identifier > that can be satisfied in two or more nearly equivalent ways. I > consider this to be a feature - not a bug. > > > > Similarly, there's a whole range of nuances between different > fingerprint matching algorithms. They differ in false positive and > false negative rates over different population samples and also > differ based on the kind and model of fingerprint sensor used. Like > the OTP case, many RPs will be content to know that a fingerprint > match mas made, without delving into and differentiating based on > every aspect of the implementation of fingerprint capture and match. > Those that want more precision than this can always define new "amr" > values. But "fpt" is fine as is for what I believe will be the 90+% > case. > > > > Ultimately, the RP is depending upon the Identity Provider to do > reasonable things. If it didn't trust the IdP to do so, it has no > business using it. The "amr" value lets the IdP signal to the RP > additional information about what it did, for the cases in which that > information is useful to the RP. > > > > Reducing this to the point of absurdity, the RP would almost never > care about the make, model, and serial number of the fingerprint > reader or OTP. Values could be defined to provide that granularity. > But making those fine-grained distinctions are not useful in > practice. > > > > Please consider the existing definitions in light of that reductio ad > absurdum. The existing values only make distinctions that are known > to be useful to RPs. Slicing things more finely than would be used > in practice actually hurts interop, rather than helping it, because > it would force all RPs to recognize that several or many different > values actually mean the same thing to them. > > > > -- Mike > > > > -Original Message- From: Stephen Farrell > [mailto:stephen.farr...@cs.tcd.ie] Sent: Monday, March 6, 2017 2:10 > PM To: Mike Jones <michael.jo...@microsoft.com>; Anthony Nadalin > <tony...@microsoft.com>; joel jaeggli <joe...@bogus.com>; The IESG > <i...@ietf.org> Cc: oauth-cha...@ietf.org; > draft-ietf-oauth-amr-val...@ietf.org; oauth@ietf.org Subject: Re: > [OAUTH-WG] Stephen Farrell's Discuss on > draft-ietf-oauth-amr-values-05: (with DISCUSS) > > > > > > Hi Mike, > > > > Apologies - I updated the discuss ballot text [1] on Feb 28 but > must've not sent it as an email or something. Anyway... > > > > [1] > https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ballot/ > > > > On 06/03/17 20:38, Mike Jones wrote: > >> Hi Stephen. The changes in draft -06 were intended to address >> your > >> DISCUSS points. Are you satisfied with these changes or are there > >> additional changes you want? I'm asking partly because it's a >> week > >> now until the submission cutoff and if additional changes are >> needed, > >> I'd like to make them this week. > > > > So I do think there's still work to be done, may as well copy the new > ballot text here: > > > > " > > I think we still have the problem that the values "defined" here > (e.g. "fpt") are under specified to a significant degree. RFC4949 > does not tell anyone how to achieve interop with "fpt" (nor any of > the other cases where you refer to 4949 I think). There is therefore > no utility in "defining" "fpt" as it will not achieve interop and in > fact is more likely to cause confusion than interop. If the solution > of actually defining the meaning of things like "fpt" is not > achievable then perhaps it will be be
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Hi Mike,
Apologies - I updated the discuss ballot text [1] on Feb 28 but
must've not sent it as an email or something. Anyway...
[1] https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ballot/
On 06/03/17 20:38, Mike Jones wrote:
> Hi Stephen. The changes in draft -06 were intended to address your
> DISCUSS points. Are you satisfied with these changes or are there
> additional changes you want? I'm asking partly because it's a week
> now until the submission cutoff and if additional changes are needed,
> I'd like to make them this week.
So I do think there's still work to be done, may as well
copy the new ballot text here:
"
I think we still have the problem that the values
"defined" here (e.g. "fpt") are under specified to a
significant degree. RFC4949 does not tell anyone
how to achieve interop with "fpt" (nor any of the
other cases where you refer to 4949 I think). There
is therefore no utility in "defining" "fpt" as it will
not achieve interop and in fact is more likely to
cause confusion than interop. If the solution of
actually defining the meaning of things like
"fpt" is not achievable then perhaps it will be
better to only define those for which we can get
interop ("pwd" and one or two others) and leave
the definition of the rest for later. (In saying that
I do recall that one of the authors said that there
are implementations that use some of these
type-names, but the point of RFCs is not to "bless"
such things, but to achieve interop.)
"
Cheers,
S.
>
> Thanks, -- Mike
>
> -Original Message- From: Mike Jones
> [mailto:michael.jo...@microsoft.com] Sent: Tuesday, February 28, 2017
> 6:17 PM To: Stephen Farrell <stephen.farr...@cs.tcd.ie>; Anthony
> Nadalin <tony...@microsoft.com>; joel jaeggli <joe...@bogus.com>; The
> IESG <i...@ietf.org> Cc: oauth-cha...@ietf.org;
> draft-ietf-oauth-amr-val...@ietf.org; oauth@ietf.org Subject: RE:
> [OAUTH-WG] Stephen Farrell's Discuss on
> draft-ietf-oauth-amr-values-05: (with DISCUSS)
>
> Hi Stephen,
>
> Draft -06 https://tools.ietf.org/html/draft-ietf-oauth-amr-values-06
> adds references for all of the defined "amr" values. Thanks for
> taking the time to have a thoughtful discussion.
>
> -- Mike
>
> -Original Message- From: Stephen Farrell
> [mailto:stephen.farr...@cs.tcd.ie] Sent: Wednesday, February 1, 2017
> 4:45 PM To: Mike Jones <michael.jo...@microsoft.com>; Anthony Nadalin
> <tony...@microsoft.com>; joel jaeggli <joe...@bogus.com>; The IESG
> <i...@ietf.org> Cc: oauth-cha...@ietf.org;
> draft-ietf-oauth-amr-val...@ietf.org; oauth@ietf.org Subject: Re:
> [OAUTH-WG] Stephen Farrell's Discuss on
> draft-ietf-oauth-amr-values-05: (with DISCUSS)
>
>
>
> On 02/02/17 00:35, Mike Jones wrote:
>> You can call me lazy if you want.
>
> I don't think you're lazy:-) Were I to guess I'd guess that interop
> for these wasn't a priority and that we're defining them a bit early
> and a little too generically.
>
>> Some of them are so well known, such as "password" or "PIN" it
>> didn't seem worthwhile to try to track down a reference.
>
> Sure, those are fine. The only issues would be if there's a
> string2key function somewhere but I don't expect there is in this
> context.
>
>> But I'm willing to work with others to find decent references for
>> the rest of them, if you believe that would improve the quality of
>> the specification.
>
> I do think it would, esp for cases where there are known different
> options (e.g. otp) or likely ill-defined or proprietary formats. My
> guess is that some biometrics fit that latter but I could be wrong.
> If they do, then one runs into the problem of having to depend on
> magic numbers in the encodings or similar to distinguish which is
> really error prone and likely to lead to what our learned transport
> chums are calling ossification;-)
>
> Cheers, S.
>
>
>>
>> Best wishes, -- Mike
>>
>> -Original Message- From: Stephen Farrell
>> [mailto:stephen.farr...@cs.tcd.ie] Sent: Wednesday, February 1,
>> 2017 4:31 PM To: Mike Jones <michael.jo...@microsoft.com>; Anthony
>> Nadalin <tony...@microsoft.com>; joel jaeggli <joe...@bogus.com>;
>> The IESG <i...@ietf.org> Cc: oauth-cha...@ietf.org;
>> draft-ietf-oauth-amr-val...@ietf.org; oauth@ietf.org Subject: Re:
>> [OAUTH-WG] Stephen Farrell's Discuss on
>> draft-ietf-oauth-amr-values-05: (with DISCUSS)
>>
>>
>>
>> On 02/02/17 00:28, Mike Jones wrote:
>>> The other case of known interop testing of "amr" value
[OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-jwsreq-12: (with COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-oauth-jwsreq-12: 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-jwsreq/ -- COMMENT: -- - intro: "attacks... have been identified." yells out for a reference - it'd be a good bit better if implementers could easily find details of some such attacks, so I hope you add some refs here. - section 3; WAP? Really? I'm surprised any WAP technology would still be in use, even on feature-phones. Do you really need this? - section 4: I think it will turn out to be an error to allow for mixing query parameters and protected parameters (in a Request Object) in a single request. Do you really need that level of flexibility? It'd be simpler and less likely to be attackable to insist that all parameters be in the Request Object if one is used. (See also section 11.2.1 below.) - section 10: Is there nothing to be said about the new indirection caused by the request_uri? I'd have thought there were some corner cases that'd warrant a mention, e.g. if some kind of deadlock or looping could happen, or if one client (in OAuth terms) could use a request_uri value as a way to attempt attacks (to be assisted by an innocent browser) against some resource owner. - section 11: thanks for that, it's good. - section 11: Saying that an ISO thing is "good to follow" is quite weak IMO. (And is that ISO spec accessible? Hmm... it seems that one needs to accept cookies to get it which is wonderfully ironic;-) If the authors have the energy, I'd suggest trying to find better guidance that's more publically available in a privacy-friendly manner. (Or just drop the ISO reference if 6973 is good enough.) ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
On 02/02/17 00:35, Mike Jones wrote: > You can call me lazy if you want. I don't think you're lazy:-) Were I to guess I'd guess that interop for these wasn't a priority and that we're defining them a bit early and a little too generically. > Some of them are so well known, > such as "password" or "PIN" it didn't seem worthwhile to try to track > down a reference. Sure, those are fine. The only issues would be if there's a string2key function somewhere but I don't expect there is in this context. > But I'm willing to work with others to find decent > references for the rest of them, if you believe that would improve > the quality of the specification. I do think it would, esp for cases where there are known different options (e.g. otp) or likely ill-defined or proprietary formats. My guess is that some biometrics fit that latter but I could be wrong. If they do, then one runs into the problem of having to depend on magic numbers in the encodings or similar to distinguish which is really error prone and likely to lead to what our learned transport chums are calling ossification;-) Cheers, S. > > Best wishes, -- Mike > > -Original Message- From: Stephen Farrell > [mailto:stephen.farr...@cs.tcd.ie] Sent: Wednesday, February 1, 2017 > 4:31 PM To: Mike Jones <michael.jo...@microsoft.com>; Anthony Nadalin > <tony...@microsoft.com>; joel jaeggli <joe...@bogus.com>; The IESG > <i...@ietf.org> Cc: oauth-cha...@ietf.org; > draft-ietf-oauth-amr-val...@ietf.org; oauth@ietf.org Subject: Re: > [OAUTH-WG] Stephen Farrell's Discuss on > draft-ietf-oauth-amr-values-05: (with DISCUSS) > > > > On 02/02/17 00:28, Mike Jones wrote: >> The other case of known interop testing of "amr" values is for >> MODRNA (OpenID Connect Mobile Profile) implementations. There's a >> reference to its use of "amr" values in the spec. > > Yeah, iirc, that one seemed ok (assuming the reference tells me what > code to write which I assume it does). > > I'm still not seeing why some do have sufficient references and > others do not. > > Is there some difficulty with finding references or something? > > S > >> >> -Original Message- From: Anthony Nadalin Sent: Wednesday, >> February 1, 2017 4:27 PM To: Stephen Farrell >> <stephen.farr...@cs.tcd.ie>; Mike Jones >> <michael.jo...@microsoft.com>; joel jaeggli <joe...@bogus.com>; >> The IESG <i...@ietf.org> Cc: oauth-cha...@ietf.org; >> draft-ietf-oauth-amr-val...@ietf.org; oauth@ietf.org Subject: RE: >> [OAUTH-WG] Stephen Farrell's Discuss on >> draft-ietf-oauth-amr-values-05: (with DISCUSS) >> >> We have interoped between FIDO authenticators vendors and Windows >> Hello >> >> -Original Message- From: Stephen Farrell >> [mailto:stephen.farr...@cs.tcd.ie] Sent: Wednesday, February 1, >> 2017 4:24 PM To: Mike Jones <michael.jo...@microsoft.com>; Anthony >> Nadalin <tony...@microsoft.com>; joel jaeggli <joe...@bogus.com>; >> The IESG <i...@ietf.org> Cc: oauth-cha...@ietf.org; >> draft-ietf-oauth-amr-val...@ietf.org; oauth@ietf.org Subject: Re: >> [OAUTH-WG] Stephen Farrell's Discuss on >> draft-ietf-oauth-amr-values-05: (with DISCUSS) >> >> >> >> On 02/02/17 00:21, Mike Jones wrote: >>> Thanks, Tony. I can add that reference. >>> >>> Stephen, the sets of initial values were chosen from those used >>> in practice by Microsoft and Google in real deployments. >> >> Genuine questions: do you aim to have interop between those >> deployments? What if I wanted to write code that'd interop with >> msft or google? >> >> S. >> >>> >>> About "otp", there are existing use cases for indicating that an >>> OTP was used. I'm not aware of any of these use cases where the >>> distinction between TOTP and HOTP is important. Thus, having >>> "otp" now makes sense, where having "hotp" and "totp" now >>> doesn't. >>> >>> Stephen, this may seem like splitting hairs, but the registry >>> instructions for "Specification Document(s)" are about having a >>> reference for the document where the Authentication Method >>> Reference Name (such as "otp") is defined. In all cases for the >>> initial values, this is the RFC-to-be, so the registry >>> instructions are satisfied. If someone were, for instance, to >>> define the string "hotp", it would be incumbent on the person >>> requesting its registr
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
On 02/02/17 00:28, Mike Jones wrote: > The other case of known interop testing of "amr" values is for MODRNA > (OpenID Connect Mobile Profile) implementations. There's a reference > to its use of "amr" values in the spec. Yeah, iirc, that one seemed ok (assuming the reference tells me what code to write which I assume it does). I'm still not seeing why some do have sufficient references and others do not. Is there some difficulty with finding references or something? S > > -Original Message- From: Anthony Nadalin Sent: Wednesday, > February 1, 2017 4:27 PM To: Stephen Farrell > <stephen.farr...@cs.tcd.ie>; Mike Jones > <michael.jo...@microsoft.com>; joel jaeggli <joe...@bogus.com>; The > IESG <i...@ietf.org> Cc: oauth-cha...@ietf.org; > draft-ietf-oauth-amr-val...@ietf.org; oauth@ietf.org Subject: RE: > [OAUTH-WG] Stephen Farrell's Discuss on > draft-ietf-oauth-amr-values-05: (with DISCUSS) > > We have interoped between FIDO authenticators vendors and Windows > Hello > > -Original Message- From: Stephen Farrell > [mailto:stephen.farr...@cs.tcd.ie] Sent: Wednesday, February 1, 2017 > 4:24 PM To: Mike Jones <michael.jo...@microsoft.com>; Anthony Nadalin > <tony...@microsoft.com>; joel jaeggli <joe...@bogus.com>; The IESG > <i...@ietf.org> Cc: oauth-cha...@ietf.org; > draft-ietf-oauth-amr-val...@ietf.org; oauth@ietf.org Subject: Re: > [OAUTH-WG] Stephen Farrell's Discuss on > draft-ietf-oauth-amr-values-05: (with DISCUSS) > > > > On 02/02/17 00:21, Mike Jones wrote: >> Thanks, Tony. I can add that reference. >> >> Stephen, the sets of initial values were chosen from those used in >> practice by Microsoft and Google in real deployments. > > Genuine questions: do you aim to have interop between those > deployments? What if I wanted to write code that'd interop with msft > or google? > > S. > >> >> About "otp", there are existing use cases for indicating that an >> OTP was used. I'm not aware of any of these use cases where the >> distinction between TOTP and HOTP is important. Thus, having >> "otp" now makes sense, where having "hotp" and "totp" now doesn't. >> >> Stephen, this may seem like splitting hairs, but the registry >> instructions for "Specification Document(s)" are about having a >> reference for the document where the Authentication Method >> Reference Name (such as "otp") is defined. In all cases for the >> initial values, this is the RFC-to-be, so the registry instructions >> are satisfied. If someone were, for instance, to define the >> string "hotp", it would be incumbent on the person requesting its >> registration to provide a URL to the document where the string >> "hotp" is defined. Also having a reference to RFC 4226 in that >> document would be a good thing, but that isn't what the registry >> instructions are about. >> >> All that said, I can look at also finding appropriate references >> for the remaining values that don't currently have them. (Anyone >> got a good reference for password or PIN to suggest, for >> instance?) >> >> -- Mike >> >> -Original Message- From: Anthony Nadalin Sent: Wednesday, >> February 1, 2017 4:10 PM To: Stephen Farrell >> <stephen.farr...@cs.tcd.ie>; Mike Jones >> <michael.jo...@microsoft.com>; joel jaeggli <joe...@bogus.com>; >> The IESG <i...@ietf.org> Cc: oauth-cha...@ietf.org; >> draft-ietf-oauth-amr-val...@ietf.org; oauth@ietf.org Subject: RE: >> [OAUTH-WG] Stephen Farrell's Discuss on >> draft-ietf-oauth-amr-values-05: (with DISCUSS) >> >> NIST asked for the addition of IRIS (as they are seeing more use >> of IRIS over retina due to the accuracy of iris) as they have >> been doing significant testing on various iris devices and continue >> to do so, here is a report that NIST released >> http://2010-2014.commerce.gov/blog/2012/04/23/nist-iris-recognition-report-evaluates-needle-haystack-search-capability.html >> >> >> >> -Original Message- From: Stephen Farrell >> [mailto:stephen.farr...@cs.tcd.ie] Sent: Wednesday, February 1, >> 2017 2:26 PM To: Mike Jones <michael.jo...@microsoft.com>; joel >> jaeggli <joe...@bogus.com>; The IESG <i...@ietf.org> Cc: >> oauth-cha...@ietf.org; draft-ietf-oauth-amr-val...@ietf.org; >> oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss >> on draft-ietf-oauth-amr-values-05: (with DISCUSS) >> >> >> Hi Mike
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Hi Tony, On 02/02/17 00:10, Anthony Nadalin wrote: > NIST asked for the addition of IRIS (as they are seeing more use of > IRIS over retina due to the accuracy of iris) as they have been > doing significant testing on various iris devices and continue to do > so, here is a report that NIST released > http://2010-2014.commerce.gov/blog/2012/04/23/nist-iris-recognition-report-evaluates-needle-haystack-search-capability.html > Sorry, but that doesn't help me (at first glance anyway). If there's a reference that'd garner us interop, then great, just add it to match the codepoint. If there's not, I don't see why adding a codepoint is useful. (Esp. if we're at the stage of testing "various iris devices" that I would guess do not get us interop.) Am I missing something? Cheers, S. > > -Original Message- From: Stephen Farrell > [mailto:stephen.farr...@cs.tcd.ie] Sent: Wednesday, February 1, 2017 > 2:26 PM To: Mike Jones <michael.jo...@microsoft.com>; joel jaeggli > <joe...@bogus.com>; The IESG <i...@ietf.org> Cc: > oauth-cha...@ietf.org; draft-ietf-oauth-amr-val...@ietf.org; > oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on > draft-ietf-oauth-amr-values-05: (with DISCUSS) > > > Hi Mike, > > On 01/02/17 17:00, Mike Jones wrote: >> Thanks for the discussion, Stephen. >> >> To your point about "otp", the working group discussed this very >> point. They explicitly decided not to introduce "hotp" and "totp" >> identifiers because no one had a use case in which the distinction >> mattered. > > Then I'm not following why adding "otp" to the registry now is a good > plan. > > If there's a use-case now, then adding an entry with a good reference > to the relevant spec seems right. > > If there's no use-case now, then not adding it to the registry seems > right. (Mentioning it as a possible future entry would be fine.) > > I think the same logic would apply for all the values that this spec > adds to the registry. Why is that wrong? > >> Others can certainly introduce those identifiers and register them >> if they do have such a use case, once the registry has been >> established. But the working group wanted to be conservative about >> the identifiers introduced to prime the registry, and this is such >> a case. >> >> What identifiers to use and register will always be a balancing >> act. You want to be as specific as necessary to add practical and >> usable value, but not so specific as to make things unnecessarily >> brittle. > > Eh... don't we want interop? Isn't that the primary goal here? > >> While some might say there's a difference between serial number >> ranges of particular authentication devices, going there is >> clearly in the weeds. On the other hand, while there used to be an >> "eye" identifier, Elaine Newton of NIST pointed out that there are >> significant differences between retina and iris matching, so "eye" >> was replaced with "retina" and "iris". Common sense informed by >> actual data is the key here. > > That's another good example. There's no reference for "iris." If that > is used in some protocol, then what format(s) are expected to be > supported? Where do I find that spec? If we can answer that, then > great, let's add the details. If not, then I'd suggest we omit "iris" > and leave it 'till later to add an entry for that. And again, > including text with "iris" as an example is just fine, all I'm asking > is that we only add the registry entry if we can meet the same bar > that we're asking the DE to impose on later additions. > > And the same for all the others... > > Cheers, S. > > >> >> The point of the registry requiring a specification reference is >> so people using the registry can tell where the identifier is >> defined. For all the initial values, that requirement is satisfied, >> since the reference will be to the new RFC. I think that aligns >> with the point that Joel was making. >> >> Your thoughts? >> >> -- Mike >> >> -----Original Message----- From: OAuth >> [mailto:oauth-boun...@ietf.org] On Behalf Of Stephen Farrell Sent: >> Wednesday, February 1, 2017 7:03 AM To: joel jaeggli >> <joe...@bogus.com>; The IESG <i...@ietf.org> Cc: >> oauth-cha...@ietf.org; draft-ietf-oauth-amr-val...@ietf.org; >> oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss >> on draft-ietf-oauth-amr-values-05: (with DISCUSS) >> >> >>
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Hi Mike, On 01/02/17 17:00, Mike Jones wrote: > Thanks for the discussion, Stephen. > > To your point about "otp", the working group discussed this very > point. They explicitly decided not to introduce "hotp" and "totp" > identifiers because no one had a use case in which the distinction > mattered. Then I'm not following why adding "otp" to the registry now is a good plan. If there's a use-case now, then adding an entry with a good reference to the relevant spec seems right. If there's no use-case now, then not adding it to the registry seems right. (Mentioning it as a possible future entry would be fine.) I think the same logic would apply for all the values that this spec adds to the registry. Why is that wrong? > Others can certainly introduce those identifiers and > register them if they do have such a use case, once the registry has > been established. But the working group wanted to be conservative > about the identifiers introduced to prime the registry, and this is > such a case. > > What identifiers to use and register will always be a balancing act. > You want to be as specific as necessary to add practical and usable > value, but not so specific as to make things unnecessarily brittle. Eh... don't we want interop? Isn't that the primary goal here? > While some might say there's a difference between serial number > ranges of particular authentication devices, going there is clearly > in the weeds. On the other hand, while there used to be an "eye" > identifier, Elaine Newton of NIST pointed out that there are > significant differences between retina and iris matching, so "eye" > was replaced with "retina" and "iris". Common sense informed by > actual data is the key here. That's another good example. There's no reference for "iris." If that is used in some protocol, then what format(s) are expected to be supported? Where do I find that spec? If we can answer that, then great, let's add the details. If not, then I'd suggest we omit "iris" and leave it 'till later to add an entry for that. And again, including text with "iris" as an example is just fine, all I'm asking is that we only add the registry entry if we can meet the same bar that we're asking the DE to impose on later additions. And the same for all the others... Cheers, S. > > The point of the registry requiring a specification reference is so > people using the registry can tell where the identifier is defined. > For all the initial values, that requirement is satisfied, since the > reference will be to the new RFC. I think that aligns with the point > that Joel was making. > > Your thoughts? > > -- Mike > > -Original Message- From: OAuth > [mailto:oauth-boun...@ietf.org] On Behalf Of Stephen Farrell Sent: > Wednesday, February 1, 2017 7:03 AM To: joel jaeggli > <joe...@bogus.com>; The IESG <i...@ietf.org> Cc: > oauth-cha...@ietf.org; draft-ietf-oauth-amr-val...@ietf.org; > oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on > draft-ietf-oauth-amr-values-05: (with DISCUSS) > > > > On 01/02/17 14:58, joel jaeggli wrote: >> On 1/31/17 8:26 AM, Stephen Farrell wrote: >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-oauth-amr-values-05: 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-amr-values/ >>> >>> >>> >>> - >>> >>> - >>> DISCUSS: >>> - >>> >>> - >>> >>> This specification seems to me to break it's own rules. You state >>> that registrations should include a reference to a specification >>> to improve interop. And yet, for the strings added here (e.g. >>> otp) you don't do that (referring to section 2 will not improve >>> interop) and there are different ways in which many of the >>> methods in section 2 can be done. So I think you need to add a >>> bunch more references. >> >> Not cle
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
On 01/02/17 14:58, joel jaeggli wrote: > On 1/31/17 8:26 AM, Stephen Farrell wrote: >> Stephen Farrell has entered the following ballot position for >> draft-ietf-oauth-amr-values-05: 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-amr-values/ >> >> >> >> -- >> DISCUSS: >> -- >> >> This specification seems to me to break it's own >> rules. You state that registrations should include >> a reference to a specification to improve interop. >> And yet, for the strings added here (e.g. otp) you >> don't do that (referring to section 2 will not >> improve interop) and there are different ways in >> which many of the methods in section 2 can be done. >> So I think you need to add a bunch more references. > > Not clear to me that the document creating the registry needs to adhere > to the rules for further allocations in order to prepoulate the > registry. that is perhaps an appeal to future consistency. Sure - I'm all for a smattering of inconsistency:-) But I think the lack of specs in some of these cases could impact on interop, e.g. in the otp case, they quote two RFCs and yet only have one value. That seems a bit broken to me, so the discuss isn't really about the formalism. S. >> >> >> > > signature.asc Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Stephen Farrell has entered the following ballot position for draft-ietf-oauth-amr-values-05: 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-amr-values/ -- DISCUSS: -- This specification seems to me to break it's own rules. You state that registrations should include a reference to a specification to improve interop. And yet, for the strings added here (e.g. otp) you don't do that (referring to section 2 will not improve interop) and there are different ways in which many of the methods in section 2 can be done. So I think you need to add a bunch more references. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Stephen Farrell's Yes on charter-ietf-oauth-04-00: (with COMMENT)
Stephen Farrell has entered the following ballot position for charter-ietf-oauth-04-00: 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-oauth/ -- COMMENT: -- FWIW, I was at the Yokohama OAuth meeting where this was discussed, and there was fairly clear consensus in the room to do this work and people willing to do it. I'm not sure if this really needs external review. I'd be fine if we just did it, but haven't checked if there's some reason to want to shoot it out to new-work. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-proof-of-possession-10: (with COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-oauth-proof-of-possession-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-proof-of-possession/ -- COMMENT: -- - Figure 1 and the discussion thereof: you talk all the time here about "a symmetric key" so I think you ought add a footnote like bit of text that says something like "note that there ought be more than one key involved here, derived from the key exchanged at (0) via a KDF." I kinda wish that all that had been covered in one document but I guess that's part of the PoP arch doc, which is for later. - 3.1 says "outside the scope of this specification": just wondering - does that phrase occur in all OAuth RFCs? (only kidding, honest:-) - section 4, para 2: replay can also be avoided if a sub-key is derived from a shared secret that is specific to the instance of the PoP demonstration. - section 6: DE guidance - I think we ought tell the DEs that the specification of a new thing needs to explicitly describe the security properties of using the new thing. - I didn't see a response to the secdir review [1] but that was maybe sent to the wrong places. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06266.html ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT)
Hi Justin, That's great thanks. I've cleared. Cheers, S. On 05/05/15 20:33, Justin Richer wrote: Stephen, We’ve incorporated this text into the latest draft: https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-29 Hopefully this will be sufficient to clear the DISCUSS. Thanks for your thoughtful review! — Justin On Apr 24, 2015, at 5:32 PM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 24/04/15 22:27, Justin Richer wrote: Stephen, I’ve worked on this this afternoon and this is my proposed text: The response to such a situation is out of scope for this specification but could include filing a report with the application developer or authorization server provider, attempted re-registration with different metadata values, or various other methods. For instance, if the server also supports a registration management mechanism such as that defined in xref target=OAuth.Registration.Management/, the client or developer could attempt to update the registration with different metadata values. This process could also be aided by a service discovery protocol such as xref target=OpenID.Discovery/ which can list a server's capabilities, allowing a client to make a more informed registration request. The use of any such management or discovery system is OPTIONAL and outside the scope of this specification. Does this text work for you? It does, nicely. Thanks, S. — Justin On Apr 24, 2015, at 8:38 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 24/04/15 13:30, Justin Richer wrote: OK, so are you asking for something like: If the server supports an update mechanism such as [Dyn-Reg-Management] and a discovery mechanism such as [OIDC-Discovery], then a smart client could use these components to renegotiate undesirable metadata values. With both of these being informative references? I'm not opposed to it. That'd work for me, yes, thanks. S. signature.asc Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT)
On 24/04/15 13:28, Justin Richer wrote: It can get as bad as the web, which is pretty bad, but I hope we don't have to point that out in great detail in every RFC that deals with the web. :) I think the drive-by-download malware example is a good one, and we could add another concrete one if you've got an idea, but I think the advice we have is sound and actionable and we should avoid having this spec be a catalogue of bad things what can happen on the web. If there is such a reference, I'm happy to point to it! That's fair. I'm not aware of a really good reference tbh. I wonder is there any relevant bits in the OAuth threat analysis? (I've not looked.) Or just a pointer to some well known incident might help. But this is a non-blocking comment, so you should feel entirely free to handle it as you think best. Cheers, S. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT)
So this is to follow up on my discuss point#2, which said: (2) If the response (defined in 3.2.1) includes metadata that the server has altered, but that the client doesn't like, then what does the client do? (It may be that that's ok, but I'm not following why that is the case.) I'm also not sure the https requirement (1st bullet in section 5) is useful there. In -28 you added a bit of text to 3.2.1. saying: The client or developer can check the values in the response to determine if the registration is sufficient for use (e.g., the registered token_endpoint_auth_method is supported by the client software) and determine a course of action appropriate for the client software. The response to such a situation is out of scope for this specification but could include filing a report with the application developer or authorization server provider. That new text may be fine, but I'd like to check that I understand it correctly and that it addresses the issue sensibly. Say I'm a developer who writes and distributes a client that uses this and I test it with the BIGreg.example.com registration endpoint and it works, but for my application to work I need a specific token_endpoint_auth_method, say client_secret_basic. Say time passes, and we discover that client_secret_basic is bad for some reason and client_secret_supergood is invented and gets used a lot. At that point BIGreg.example.com would like to turn off the (now-crappy) client_secret_basic and only allow use of client_secret_supergood. If it does that, then new installs of our application will fail at registration time with an (opaque) error to the human user and we need the application developer to do an update to add client_secret_supergood. Or, what seems more likely is that BIGreg.example.com will have to keep offering the now insecure client_secret_basic until essentially no interesting applications remain that don't support the new, better thing. And that's the bit I don't like so much. This spec could (maybe, I'm not 100% sure) have been written to allow for the client and registration endpoint to first try to use the new better things and, if that doesn't work, to try fallback to the old not so good things, but that is not supported here afaics - once the client sees response metadata it doesn't like, there's no way for the client to say bummer, I'd have been fine if only you'd said foo and not bar, can we try register again and use foo? And I also don't see how the client who is really stuck can tell the registration endpoint actually, I'm not successfully registered because your said bar and I don't like that bit of metadata - won't that lead to our BIGreg.example.com ending up with a misleading picture of what clients were successfully registered? So my question is: is all that really ok, or am I confused in the above? (And confused is quite possible - this is OAuth after all:-) Cheers, S. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT)
On 24/04/15 13:20, Justin Richer wrote: Stephen, thanks for the comments. We discussed but decided to stop short of a full back-and-forth multi-trip information negotiation protocol in order to keep things as simple as possible for the simple case. The model here is that the client *requests* a certain set of information in the registration, and the server *dictates* to the client what actually occurred. This is to allow sensible defaults for blank fields, and other mechanisms like that. Instead of just saying no, the server here has an opportunity to do something slightly reasonable. It's up to the client if it agrees with the reasonableness, and most clients (in my experience) are going to be super dumb and just do what they're told by the server if they're able to. If they're unable to, they'll just fail to use the OAuth protocol with that AS and users will complain (rightly) of an incompatibility bug. A smarter client can try to re-register and see if that works instead, but the vast majority of OAuth clients are really dumb (by design). However, there's a bit more to the story: As it turns out, when coupled with the management protocol and a discovery mechanism, you actually can do more of a negotiated registration with the existing mechanism: client says I want foo, server says you get bar, client sends an UPDATE that says can I have baz instead?, and so forth. Without the update mechanism, you don't have a way to tie one registration request to a subsequent one. If you've got server capability discovery (such as is defined in OpenID Connect and still-ignored by this working group) then you've got the ability for a smart client to see which values might work ahead of time. This gets a little tricky with values that have relationships (such as grant_types and response_types), but it's still workable when they've got well-defined relationships (as is required in the Dyn Reg spec). So it really is out of scope for us to say what the client does when it gets information back it doesn't want: it can ignore it, fail on it, or use it. With management and discovery, it can try to re-negotiate, but that's a fairly sophisticated behavior. So could we just point at the relevant specs for that behaviour? (Not normatively, and I don't care if they're not RFCs.) S. Hope this helps, -- Justin On 4/24/2015 8:09 AM, Stephen Farrell wrote: So this is to follow up on my discuss point#2, which said: (2) If the response (defined in 3.2.1) includes metadata that the server has altered, but that the client doesn't like, then what does the client do? (It may be that that's ok, but I'm not following why that is the case.) I'm also not sure the https requirement (1st bullet in section 5) is useful there. In -28 you added a bit of text to 3.2.1. saying: The client or developer can check the values in the response to determine if the registration is sufficient for use (e.g., the registered token_endpoint_auth_method is supported by the client software) and determine a course of action appropriate for the client software. The response to such a situation is out of scope for this specification but could include filing a report with the application developer or authorization server provider. That new text may be fine, but I'd like to check that I understand it correctly and that it addresses the issue sensibly. Say I'm a developer who writes and distributes a client that uses this and I test it with the BIGreg.example.com registration endpoint and it works, but for my application to work I need a specific token_endpoint_auth_method, say client_secret_basic. Say time passes, and we discover that client_secret_basic is bad for some reason and client_secret_supergood is invented and gets used a lot. At that point BIGreg.example.com would like to turn off the (now-crappy) client_secret_basic and only allow use of client_secret_supergood. If it does that, then new installs of our application will fail at registration time with an (opaque) error to the human user and we need the application developer to do an update to add client_secret_supergood. Or, what seems more likely is that BIGreg.example.com will have to keep offering the now insecure client_secret_basic until essentially no interesting applications remain that don't support the new, better thing. And that's the bit I don't like so much. This spec could (maybe, I'm not 100% sure) have been written to allow for the client and registration endpoint to first try to use the new better things and, if that doesn't work, to try fallback to the old not so good things, but that is not supported here afaics - once the client sees response metadata it doesn't like, there's no way for the client to say bummer, I'd have been fine if only you'd said foo and not bar, can we try register again and use foo? And I also don't see how the client who is really stuck can
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT)
On 24/04/15 13:30, Justin Richer wrote: OK, so are you asking for something like: If the server supports an update mechanism such as [Dyn-Reg-Management] and a discovery mechanism such as [OIDC-Discovery], then a smart client could use these components to renegotiate undesirable metadata values. With both of these being informative references? I'm not opposed to it. That'd work for me, yes, thanks. S. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT)
On 24/04/15 22:27, Justin Richer wrote: Stephen, I’ve worked on this this afternoon and this is my proposed text: The response to such a situation is out of scope for this specification but could include filing a report with the application developer or authorization server provider, attempted re-registration with different metadata values, or various other methods. For instance, if the server also supports a registration management mechanism such as that defined in xref target=OAuth.Registration.Management/, the client or developer could attempt to update the registration with different metadata values. This process could also be aided by a service discovery protocol such as xref target=OpenID.Discovery/ which can list a server's capabilities, allowing a client to make a more informed registration request. The use of any such management or discovery system is OPTIONAL and outside the scope of this specification. Does this text work for you? It does, nicely. Thanks, S. — Justin On Apr 24, 2015, at 8:38 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 24/04/15 13:30, Justin Richer wrote: OK, so are you asking for something like: If the server supports an update mechanism such as [Dyn-Reg-Management] and a discovery mechanism such as [OIDC-Discovery], then a smart client could use these components to renegotiate undesirable metadata values. With both of these being informative references? I'm not opposed to it. That'd work for me, yes, thanks. S. signature.asc Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Fwd: [Unbearable] one proposal for a charter - please dicsuss
Hiya, I've kicked off that discussion on the unbearable list. *Please* let's have the discussion there. On one mailing list, not two. Thanks, S. Forwarded Message Subject: [Unbearable] one proposal for a charter - please dicsuss Date: Mon, 08 Dec 2014 23:19:28 + From: Stephen Farrell stephen.farr...@cs.tcd.ie To: unbeara...@ietf.org Hi all, There's about 70+ people on the list now so let's kick off. Andrei sent Kathleen and I the charter proposal below a while ago. For myself I don't think its quite right yet but I'd rather hear what you all think. So please discuss... Cheers, S. Token Binding (TB) Charter for Working Group Web services generate various security tokens (e.g. HTTP cookies, OAuth tokens, etc.) for web applications to access protected resources. Currently these are bearer tokens, i.e. any party in possession of such token gains access to the protected resource. Attackers export bearer tokens from client machines or from compromised network connections, present these bearer tokens to Web services, and impersonate authenticated users. The idea of Token Binding is to prevent such attacks by cryptographically binding security tokens to the TLS layer. The tasks of this working group are as follows: 1.Specify the Token Binding protocol v1.0. 2.Specify the use of the Token Binding protocol in combination with HTTPS. It is a goal of this working group to prevent security token export and replay attacks, but other issues associated with the use of security tokens are out of scope. It is a goal of this working group to design the Token Binding protocol such that it would be also useable with application protocols other than HTTPS, however specifying such uses is not a primary goal. Some of the main design goals for the Token Binding protocol, in no particular order: 1.Prevent export and replay of security tokens. 2.Allow strong key protection, e.g. using hardware-bound keys. 3.Support both first-party and federation scenarios. 4.Preserve user privacy. 5.Make the Token Binding protocol useable in combination with a variety of application protocols. 6.Allow the negotiation of the Token Binding protocol without additional round-trips. 7.Allow the use of multiple cryptographic algorithms, so that a variety of secure hardware modules with different cryptographic capabilities could be used with Token Binding. The working group will use the following documents as a starting point for its work: - draft-popov-token-binding-00; - draft-balfanz-https-token-binding-00. This WG will collaborate with other IETF WGs, in particular with the TLS, HTTPbis and Oauth WGs. Milestones: March 2015: WG document for the Token Binding Protocol v1.0. March 2015: WG document for HTTPS Token Binding. November 2015: Token Binding Protocol v1.0 to IESG. November 2015: HTTPS Token Binding to IESG. ___ Unbearable mailing list unbeara...@ietf.org https://www.ietf.org/mailman/listinfo/unbearable ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: [websec] unbearable - new mailing list to discuss better than bearer tokens...
Hiya, Sorry - I should have posted the announce here too. Not doing so was just an oversight. Discussion of overlaps between the newly proposed and existing work is a fine topic for the new list I'd say. But better there than here. Cheers, S On 6 December 2014 11:42:57 GMT+00:00, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: I think it should be the responsibility of document authors to read the the state of the art to avoid re-inventing the wheel (particularly since their co-workers have been heavily involved in the work). It is not true that we have been waiting for 4 years for this now since they have changed their solution approach many times and the use of the raw public key in combination with the PoP solution would have given a complete solution. Ciao Hannes On 12/06/2014 11:09 AM, John Bradley wrote: They have examples of how it could be used in OAuth and Connect. They didn't look at what we were doing with PoP so the examples don't line up. That is why it is important to keep on top of this so that it is the OAuth WG that is defining how this binding mechanism is used in OAuth and JWT. The specs themselves are, or should be independent of token type. We have been waiting for TLS to produce this for around 4 years now. It is not really new work, mostly a change of venue to make progress. All of this was discussed at the last IETF meeting. I thought a significant number of people from the OAuth WG were in the room. John B. On Dec 6, 2014, at 6:28 AM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: I agree with Phil. As currently described it replicates a lot of the work we have done in PoP. Ciao Hannes On 12/06/2014 09:52 AM, John Bradley wrote: No, this is the the work formerly known as origin bound certificates Channel ID. We need this to bind id_tokens and or access tokens to TLS sessions. So it is an alternative TLS binding mechanism. We still need to describe how to use it with OAuth and JWT. It is a building block we can use for PoP. John B. On Dec 5, 2014, at 10:48 PM, Phil Hunt phil.h...@oracle.com wrote: Doesn't that duplicate our current work? Phil On Dec 5, 2014, at 11:17, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Forwarded Message Subject: [websec] unbearable - new mailing list to discuss better than bearer tokens... Date: Fri, 05 Dec 2014 16:43:19 + From: Stephen Farrell stephen.farr...@cs.tcd.ie Reply-To: Stephen Farrell stephen.farr...@cs.tcd.ie To: s...@ietf.org s...@ietf.org, websec web...@ietf.org, u...@ietf.org u...@ietf.org, ietf-http...@w3.org Group ietf-http...@w3.org, http-a...@ietf.org http-a...@ietf.org Hiya, Following up on the presentation at IETF-91 on this topic, [1] we've created a new list [2] for moving that along. The list description is: This list is for discussion of proposals for doing better than bearer tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks. If you're interested please join in. Thanks to Vinod and Andrei for agreeing to admin the list. We'll kick off discussion in a few days when folks have had a chance to subscribe. Cheers, S. PS: Please don't reply-all to this, join the new list, wait a few days and then say what you need to say:-) [1] https://tools.ietf.org/agenda/91/slides/slides-91-uta-2.pdf [2] https://www.ietf.org/mailman/listinfo/unbearable ___ websec mailing list web...@ietf.org https://www.ietf.org/mailman/listinfo/websec ___ 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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [http-auth] unbearable - new mailing list to discuss better than bearer tokens...
Hi Phil, Good points that need discussing but I'd suggest we give the new list a few days to allow folks to subscribe and then have that discussion. Thanks, S. On 06/12/14 16:08, Phil Hunt wrote: On the surface (as currently presented) this work appears to duplicate the POP work going on in OAuth. The key difference is that this work is focused on using ALPN to bind tokens to the TLS channel. From a use case perspective it is very close to OAuth POP, and a specific use case of the current OAuth POP (proof of possession) architecture. I note that the OAuth WG had originally dropped TLS binding in part because TLS was not always end-to-end in cases where load-balancers where used. The identified use-cases required end-to-end proof of possession (e.g. to prevent token re-use and relaying). Never-the-less, events and approaches change and this is worth discussing (again). I think the architectural/protocol issues around the use of load balancers have to be discussed as the current ALPN proposal may be unbearable for many. Phil @independentid www.independentid.com phil.h...@oracle.com On Dec 5, 2014, at 8:43 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: Hiya, Following up on the presentation at IETF-91 on this topic, [1] we've created a new list [2] for moving that along. The list description is: This list is for discussion of proposals for doing better than bearer tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks. If you're interested please join in. Thanks to Vinod and Andrei for agreeing to admin the list. We'll kick off discussion in a few days when folks have had a chance to subscribe. Cheers, S. PS: Please don't reply-all to this, join the new list, wait a few days and then say what you need to say:-) [1] https://tools.ietf.org/agenda/91/slides/slides-91-uta-2.pdf [2] https://www.ietf.org/mailman/listinfo/unbearable ___ http-auth mailing list http-a...@ietf.org https://www.ietf.org/mailman/listinfo/http-auth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)
Yeah I think that's fair (though regrettable:-). Will look at it before the meeting. S On 12/11/14 00:03, Mike Jones wrote: Hi Stephen, Your DISCUSS on alg:none being MTI is the only one remaining on the JWT draft. Given the working group support for keeping things the way they are, would you be willing to clear this DISCUSS on that basis? The OAuth WG meeting is tomorrow, so it would be good to hear your thoughts before then, if possible. Thanks, -- Mike -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Friday, October 24, 2014 8:33 PM To: 'Stephen Farrell'; The IESG Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web-to...@tools.ietf.org; oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) Hi Stephen, I applied your privacy wording to the -30 draft. Thanks. About your DISCUSS on alg:none being MTI, several working group members have chimed in agreeing that it should continue to be MTI, and said why. In summary - unsigned security tokens representing claims are really common in identity protocols; interop will be improved if this functionality is MTI. Can I therefore ask you hold your nose a little bit more and clear this remaining DISCUSS? Thanks again, -- Mike -Original Message- From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] Sent: Tuesday, October 21, 2014 6:17 AM To: Mike Jones; The IESG Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web-to...@tools.ietf.org; oauth@ietf.org Subject: Re: Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) Hi Mike, I've one remaining discuss point and a comment. See below... On 14/10/14 13:50, Mike Jones wrote: The proposed resolutions below have been included in the -28 draft. Hopefully you'll be able to clear your DISCUSSes on that basis. The String Comparison Rules in Section 7.3 have been expanded to talk about when the application may need canonicalization rules. Thanks again, -- Mike -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Monday, October 06, 2014 7:20 PM To: Stephen Farrell; The IESG Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web- to...@tools.ietf.org; oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json- web-token-27: (with DISCUSS and COMMENT) Thanks for tracking all of this Stephen. Responses inline below... -Original Message- From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] Sent: Monday, October 06, 2014 2:43 PM To: Mike Jones; The IESG Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web- to...@tools.ietf.org; oauth@ietf.org Subject: Re: Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) Hi Mike, On 06/10/14 08:54, Mike Jones wrote: Thanks for your review, Stephen. I've added the working group to the thread so they're aware of your comments. -Original Message- From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] Sent: Thursday, October 02, 2014 5:03 AM To: The IESG Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web- to...@tools.ietf.org Subject: Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) Stephen Farrell has entered the following ballot position for draft-ietf-oauth-json-web-token-27: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ -- - -- - DISCUSS: -- - -- - (1) 4.1.1 and elsewhere you say case-sensitive: the same thing I raised wrt DNS names for another JOSE spec - do you need to say those SHOULD be [upper|lower]cased when used in these? I believe that somewhere we should say that if case-insensitive values, such as DNS names, are used when constructing kid values, that the application doing so needs to define a convention on the canonical case to use for the case-insensitive portions, such as lowercasing them. As that discussion's happening on the key draft, I'll clear it here and trust you to fix if a change is the end
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)
Hi Mike, I've one remaining discuss point and a comment. See below... On 14/10/14 13:50, Mike Jones wrote: The proposed resolutions below have been included in the -28 draft. Hopefully you'll be able to clear your DISCUSSes on that basis. The String Comparison Rules in Section 7.3 have been expanded to talk about when the application may need canonicalization rules. Thanks again, -- Mike -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Monday, October 06, 2014 7:20 PM To: Stephen Farrell; The IESG Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web- to...@tools.ietf.org; oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json- web-token-27: (with DISCUSS and COMMENT) Thanks for tracking all of this Stephen. Responses inline below... -Original Message- From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] Sent: Monday, October 06, 2014 2:43 PM To: Mike Jones; The IESG Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web- to...@tools.ietf.org; oauth@ietf.org Subject: Re: Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) Hi Mike, On 06/10/14 08:54, Mike Jones wrote: Thanks for your review, Stephen. I've added the working group to the thread so they're aware of your comments. -Original Message- From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] Sent: Thursday, October 02, 2014 5:03 AM To: The IESG Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web- to...@tools.ietf.org Subject: Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) Stephen Farrell has entered the following ballot position for draft-ietf-oauth-json-web-token-27: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ --- -- - DISCUSS: --- -- - (1) 4.1.1 and elsewhere you say case-sensitive: the same thing I raised wrt DNS names for another JOSE spec - do you need to say those SHOULD be [upper|lower]cased when used in these? I believe that somewhere we should say that if case-insensitive values, such as DNS names, are used when constructing kid values, that the application doing so needs to define a convention on the canonical case to use for the case-insensitive portions, such as lowercasing them. As that discussion's happening on the key draft, I'll clear it here and trust you to fix if a change is the end result. Thanks np (2) Section 8: Why is none MTI? That seems both broken and going in the oppostite direction from other WGs and so should be explicitly jusified I think. (If a good enough justification exists that is.) It is MTI because there are several existing applications of JWTs in which both unsigned and signed representations of the JWTs are requirements. These include draft-ietf-oauth-token-exchange, draft-hunt-oauth-v2-user-a4c, and OpenID Connect. This is a pretty common pattern where you sign something if the recipient cares who made the statements and where you don't have to sign it either if the recipient doesn't care who made the statements I don't see how (non-)signers can divine non-verifier's wishes that way. (Absent negotiation or a directory.) Sometimes it does occur via negotiation. For instance, in some protocols, at registration time, relying parties explicitly tell identity providers what algorithms are acceptable to them, which may include none. No divination - explicit communication. or if it can tell from another secured aspect of the application protocol (typically through the use of TLS) who made the statements. In the TLS case, the server authentication step makes a signature step unnecessary, so an Unsecured JWT is fine there. That's arguable IMO. I agree that it's application and context-dependent whether it's OK or not. The point is that there exist some circumstances in which it is OK, and this feature is being used in some of those cases. I think I'll look back over the wg thread and either hold my nose or This issue was tracked as http://trac.tools.ietf.org/wg/jose/trac/ticket/36. Karen O'Donoghue recorded this conclusion in the tracker Note: There was extensive discussion on the mailing list, and the rough consensus of the working group was to leave none
[OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-assertions-18: (with COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-oauth-assertions-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 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: -- Thanks for adding the MTI algorithms to the saml and jwt docs to clear the discuss I put on this one. I didn't check the comments below. - general: What prevents/detects conflicts between the oauth scope parameter and the saml or jwt equivalent? Are there other bits of replicated data that could be the basis for a vulnerability? (The comment below applies for both saml and jwt so putting it here.) - The no replay protection issue was debated in the WG wasn't it? (I think I recall it, not sure.) Seems like a bad plan to me to not require at least implementation of replay protection in the AS so that it can be turned on. Can you point me at where that was discussed on the list? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-oauth-saml2-bearer-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ -- COMMENT: -- - intro para2: might be nice (no more) to add some refs to other protocols that use SAML. - 2.2: What are padding bits in 4648? I don't recall such. (But may be misremembering.) - section 3, list item 2: This doesn't quite say that the token endpoint URL MUST (in the absence of another profile) be in an Audience element. Why not? The text seems to me to allow for the AS to map the token endpoint URL to any value in an Audience element that the AS finds ok. I suspect that might be unwise, but it at least needs to be clear. Is that the text being ambiguous or me being paranoid/wrong? Same point seems to apply elsewhere too: = in item 3.A where it says typically identifies but does not say how. = in item 5 or an acceptable alias - section 3, item 7: How might an AS know that the Assertion was issued with the intention that the client act autonomously on behalf of the subject? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-oauth-assertions-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ -- DISCUSS: -- Putting one discuss here rather than one on each of the other docs. We can fix that as appropriate after we chat. Where are the MTI signature and mac algs for these specified? If those can be tracked back via the SAML and jose docs that's fine, but I'm not sure if they are. -- COMMENT: -- - general: What prevents/detects conflicts between the oauth scope parameter and the saml or jwt equivalent? Are there other bits of replicated data that could be the basis for a vulnerability? (The comment below applies for both saml and jwt so putting it here.) - The no replay protection issue was debated in the WG wasn't it? (I think I recall it, not sure.) Seems like a bad plan to me to not require at least implementation of replay protection in the AS so that it can be turned on. Can you point me at where that was discussed on the list? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-jwt-bearer-10: (with COMMENT)
Stephen Farrell has entered the following ballot position for draft-ietf-oauth-jwt-bearer-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 http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ -- COMMENT: -- - 2.1, assertion parameter: How come this one does not talk about base64url whereas the saml one does? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-jwt-bearer-10: (with COMMENT)
Ah fair enough, forgot that. S. On 16/10/14 14:10, Brian Campbell wrote: A JWT, by it's very definition, is a set of base64url pieces concatenated together with dot . characters (which is also URL safe). So no additional encoding or serialization of the JWT is needed. On Thu, Oct 16, 2014 at 5:22 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: Stephen Farrell has entered the following ballot position for draft-ietf-oauth-jwt-bearer-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 http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ -- COMMENT: -- - 2.1, assertion parameter: How come this one does not talk about base64url whereas the saml one does? ___ 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
Re: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT)
Hiya, Mostly fine just a couple of notes. On 16/10/14 20:28, Brian Campbell wrote: Thanks for your review and feedback, Stephen. Replies are inline below... On Thu, Oct 16, 2014 at 5:20 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: Stephen Farrell has entered the following ballot position for draft-ietf-oauth-saml2-bearer-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ -- COMMENT: -- - intro para2: might be nice (no more) to add some refs to other protocols that use SAML. OK - 2.2: What are padding bits in 4648? I don't recall such. (But may be misremembering.) FWIW, that exact wording was suggested to me by Peter Saint-Andre (cc'd) so, trusting in him, I just took the text without question. But I believe it means and is basically just restating what is said near the middle/end of §4 in 4648, When fewer than 24 input bits are available in an input group, bits with value zero are added (on the right) to form an integral number of 6-bit groups. - https://tools.ietf.org/html/rfc4648#section-4 Are you saying Peter is wrong? ;) Heh. - section 3, list item 2: This doesn't quite say that the token endpoint URL MUST (in the absence of another profile) be in an Audience element. Why not? The text seems to me to allow for the AS to map the token endpoint URL to any value in an Audience element that the AS finds ok. I suspect that might be unwise, but it at least needs to be clear. Is that the text being ambiguous or me being paranoid/wrong? You are not wrong. But it's intentionally that way to allow for how this will actually be used and deployed (and currently is). It accommodates how SAML defines audience (SAML core 2.5.1.4 referenced in item 2 there) as well as providing the token endpoint URL as a means of identifying the AS as an audience for deployments that wouldn't otherwise have a SAML 2.0 entity id to use. This profile is just a small piece of a bigger picture and, as such, needs to fit into the larger picture. Oftentimes it will be deployed as a complement to existing SAML deployments where trust has already been established and keys and identifiers have already been exchanged, in which case the existing SAML 2.0 entity ID of the AS who is a SAML SP in that context should be used as the audience. But I couldn't presume that would always be the case so needed to provide some guidance for what to use as the audience in the absence of a larger SAML deployment. OAuth doesn't have any kind of discovery or metadata, only endpoints to identify an AS, and this draft isn't going to address that. So the token endpoint is really the only option. I understand the desire to have something neat and tidy here but it's just not feasible to do so and reconcile with the way this kind of software is actually deployed and used. Some stuff needs to be exchanged out-of-band for this to work. Entity/issuer/audience identifiers are part of that. This need is discussed in the Interoperability Considerations at https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5 So I think it'd be good to explicitly call out that these mappings are basically required and that they can be fraught (e.g. if someone uses wildcards badly, which they do). Cheers, S. Same point seems to apply elsewhere too: = in item 3.A where it says typically identifies but does not say how. Could be an email, a username, a guid, a distinguished name, a certificate, a persistent pseudonymous id, a transient pseudonymous id, etc. Like all cross domain identity systems, part of the deployment is determining how identities will be conveyed. Nailing that down any more is way beyond the scope of this draft. It's also mentioned in the Interoperability Considerations. https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5 = in item 5 or an acceptable alias To give the AS some flexibility in what it accepts as identifying itself. - section 3, item 7: How might an AS know that the Assertion was issued with the intention that the client act autonomously on behalf of the subject? Item 7 is intended to provide a way to single that to the AS - and it's really about if the user directly authenticated or not. The issuer of the assertion will know (usually) if the user authenticated directly or if the assertion is being issued about
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)
Hiya, On 16/10/14 21:06, Brian Campbell wrote: Thanks for your review and feedback on this one too, Stephen. Replies are inline below... On Thu, Oct 16, 2014 at 5:22 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: Stephen Farrell has entered the following ballot position for draft-ietf-oauth-assertions-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ -- DISCUSS: -- Putting one discuss here rather than one on each of the other docs. We can fix that as appropriate after we chat. Where are the MTI signature and mac algs for these specified? If those can be tracked back via the SAML and jose docs that's fine, but I'm not sure if they are. I believe they can be. JOSE Implementation Requirements for JWS are in the table in JWA §3.1 https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-34#section-3.1 And there's §5 SAML and XML Signature Syntax and Processing http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf Hmm. So the SAML one only seems to have RSA-SHA1 as the MTI and the JOSE one has only H256 as required. Doesn't that seem like one is unacceptably old and the other is not great for this purpose? My suggestion would be to add rsa-sha256 as MTI for these, as an addition to whatever JOSE and SAML make MTI. But I'd be happy to clear if you made any modern signature alg MTI. Cheers, S. PS: Stuff below is fine. -- COMMENT: -- - general: What prevents/detects conflicts between the oauth scope parameter and the saml or jwt equivalent? Are there other bits of replicated data that could be the basis for a vulnerability? (The comment below applies for both saml and jwt so putting it here.) Scope is not represented inside the assertion (JWT or SAML) so there's no potential for conflict. - The no replay protection issue was debated in the WG wasn't it? (I think I recall it, not sure.) Seems like a bad plan to me to not require at least implementation of replay protection in the AS so that it can be turned on. Can you point me at where that was discussed on the list? I described my recollection and justification of the optionality of one particular type of replay protection in a message yesterday: http://www.ietf.org/mail-archive/web/oauth/current/msg13567.html It's worth mentioning that there are different ideas of what replay is and what to protect against. The one particular type mentioned above is pretty narrow - checking to see if the same token is used again at the same relying party. There are other kinds of more sinister replay which are prevented by properly audience restricting the assertions. The audience restriction let's the issuer say specifically what relying party is allowed to consume the assertion, which ensures that the client can't use it somewhere where it wasn't intended and that the relying party that receives the assertion can't turn around and use it to access some other service. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)
On 16/10/14 22:39, Brian Campbell wrote: Hiya in return and inline below... On Thu, Oct 16, 2014 at 3:00 PM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: Hmm. So the SAML one only seems to have RSA-SHA1 as the MTI and the JOSE one has only H256 as required. Doesn't that seem like one is unacceptably old and the other is not great for this purpose? Admittedly, I was a little worried you'd say that :) I'm glad we're not surprising one another:-) My suggestion would be to add rsa-sha256 as MTI for these, as an addition to whatever JOSE and SAML make MTI. But I'd be happy to clear if you made any modern signature alg MTI. Honestly, in my view, an MIT on these doesn't make a whole lot of sense as I think what's actually implemented/supported will be dictated by the larger deployments of SAML/SAMLP or JWT/JOSE/OpenID Connect. My feeling is that an MIT in these specs would likely be ignored and/or not influence implementers/deployers. So my preference would be to leave MTI out of these. But if you're not swayed by that line of thinking, and I'm guessing you're not, rsa-sha256 is probably the most appropriate choice. Could you give some guidance and/or point to examples of where and how to say that appropriately in the documents? Thanks! Sure, I'd say probably best is for the jwt one to say that RS256 MUST be supported and for the saml one say that [1] MUST be supported. (Check [2] for rsa-sha256 for some text) A sentence in each is all's needed. Cheers, S. [1] http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 [2] http://www.w3.org/TR/2013/NOTE-xmlsec-algorithms-20130411/ Cheers, S. PS: Stuff below is fine. Great, thank you. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)
Hi Mike, On 06/10/14 08:54, Mike Jones wrote: Thanks for your review, Stephen. I've added the working group to the thread so they're aware of your comments. -Original Message- From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] Sent: Thursday, October 02, 2014 5:03 AM To: The IESG Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web- to...@tools.ietf.org Subject: Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) Stephen Farrell has entered the following ballot position for draft-ietf-oauth-json-web-token-27: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ -- DISCUSS: -- (1) 4.1.1 and elsewhere you say case-sensitive: the same thing I raised wrt DNS names for another JOSE spec - do you need to say those SHOULD be [upper|lower]cased when used in these? I believe that somewhere we should say that if case-insensitive values, such as DNS names, are used when constructing kid values, that the application doing so needs to define a convention on the canonical case to use for the case-insensitive portions, such as lowercasing them. As that discussion's happening on the key draft, I'll clear it here and trust you to fix if a change is the end result. (2) Section 8: Why is none MTI? That seems both broken and going in the oppostite direction from other WGs and so should be explicitly jusified I think. (If a good enough justification exists that is.) It is MTI because there are several existing applications of JWTs in which both unsigned and signed representations of the JWTs are requirements. These include draft-ietf-oauth-token-exchange, draft-hunt-oauth-v2-user-a4c, and OpenID Connect. This is a pretty common pattern where you sign something if the recipient cares who made the statements and where you don't have to sign it either if the recipient doesn't care who made the statements I don't see how (non-)signers can divine non-verifier's wishes that way. (Absent negotiation or a directory.) or if it can tell from another secured aspect of the application protocol (typically through the use of TLS) who made the statements. In the TLS case, the server authentication step makes a signature step unnecessary, so an Unsecured JWT is fine there. That's arguable IMO. I think I'll look back over the wg thread and either hold my nose or (3) Section 12: another way to handle privacy is to not include sensitive data - I think you ought mention that as a bit of thought along those lines can be much simpler than putting in place the key management to handle thoughtlessly included PII. We can include a discussion of that point, Great. Just say no is workable here:-) I'll clear when we get such text. but sometimes the very point of a JWT is to securely deliver PII from a verifiable party to an intended party with appropriate rights to receive it. Hmm. Its a moot point (so let's not argue it) but I wonder how often PII is really needed for authorization with oauth. My guess would be that its needed far less often than its found to be profitable perhaps, or that carelessness plays a big role in using PII for such purposes. S. -- COMMENT: -- - abstract: 2nd sentence isn't needed here, in intro would be fine. I don't know - I think it's a big deal that the claims can be digitally signed or MACed and/or encrypted. That's the reason we have JWTs, rather than just JSON. - 4.1.7: maybe worth adding that jti+iss being unique enough is not sufficient and jti alone has to meet that need. In X.509 the issuer/serial has the equivalent property so someone might assume sequential jti values starting at 0 are ok. Makes sense to add a warning of some kind along these lines. I think I know the reasons you say that, but can you expand on that thought a bit before I take a stab on writing this up? For instance, while normally true, I don't think your observation is true if a relying party will only accept tokens from a single issuer. - section 6: yuk - again I think the secdir comments are being handled by Kathleen and the authors. Again, this is there because multiple applications asked for the ability to represent content that is optionally signed, sometimes
Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS)
Mike, I cannot tell which is your text and which not. Can you please use a better quoting style? These docs are going to be a total PITA to handle otherwise. Thanks, S. On 02/10/14 16:14, Mike Jones wrote: Responding to the DISCUSS below… -Original Message- From: Alissa Cooper [mailto:ali...@cooperw.in] Sent: Wednesday, October 01, 2014 12:25 PM To: The IESG Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web-to...@tools.ietf.org Subject: Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS) Alissa Cooper has entered the following ballot position for draft-ietf-oauth-json-web-token-27: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ -- DISCUSS: -- == Section 12 == A JWT may contain privacy-sensitive information. When this is the case, measures must be taken to prevent disclosure of this information to unintended parties. It seems to me that this should be a normative MUST, particularly in light of the fact that claims are being defined that are meant to directly identify users (e.g., sub) and other claims defined here or later could do so as well. There seems to be debate whether a 2119 language should be used other than when describing protocol requirements. Jim Schaad (the JOSE chair) believes that they shouldn’t and these documents have followed that convention. One way to achieve this is to use an encrypted JWT. Another way is to ensure that JWTs containing unencrypted privacy-sensitive information are only transmitted over encrypted channels or protocols, such as TLS. Since sensitive JWTs should be protected from both intermediary observation and from being sent to unintended recipients, I would suggest: One way to achieve this is to use an encrypted JWT and authenticate the recipient. Another way is to ensure that JWTs containing unencrypted privacy-sensitive information are only transmitted over encrypted channels or protocols that also support endpoint authentication, such as TLS. Thanks for this suggested language. We can incorporate something like that. ___ 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
Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS)
On 02/10/14 17:25, Mike Jones wrote: OK - I'll start prefixing my text with Mike . Many thanks. S -Original Message- From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] Sent: Thursday, October 02, 2014 8:49 AM To: Mike Jones; Alissa Cooper; The IESG Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web-to...@tools.ietf.org; oauth@ietf.org Subject: Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS) Mike, I cannot tell which is your text and which not. Can you please use a better quoting style? These docs are going to be a total PITA to handle otherwise. Thanks, S. On 02/10/14 16:14, Mike Jones wrote: Responding to the DISCUSS below… -Original Message- From: Alissa Cooper [mailto:ali...@cooperw.in] Sent: Wednesday, October 01, 2014 12:25 PM To: The IESG Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web-to...@tools.ietf.org Subject: Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS) Alissa Cooper has entered the following ballot position for draft-ietf-oauth-json-web-token-27: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ -- DISCUSS: -- == Section 12 == A JWT may contain privacy-sensitive information. When this is the case, measures must be taken to prevent disclosure of this information to unintended parties. It seems to me that this should be a normative MUST, particularly in light of the fact that claims are being defined that are meant to directly identify users (e.g., sub) and other claims defined here or later could do so as well. There seems to be debate whether a 2119 language should be used other than when describing protocol requirements. Jim Schaad (the JOSE chair) believes that they shouldn’t and these documents have followed that convention. One way to achieve this is to use an encrypted JWT. Another way is to ensure that JWTs containing unencrypted privacy-sensitive information are only transmitted over encrypted channels or protocols, such as TLS. Since sensitive JWTs should be protected from both intermediary observation and from being sent to unintended recipients, I would suggest: One way to achieve this is to use an encrypted JWT and authenticate the recipient. Another way is to ensure that JWTs containing unencrypted privacy-sensitive information are only transmitted over encrypted channels or protocols that also support endpoint authentication, such as TLS. Thanks for this suggested language. We can incorporate something like that. ___ 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: [kitten] [IANA #731918] SASL mechanism not listed
See below. I think (not quite sure) that this is better discussed on the kitten list. Ta, S. Original Message Subject: [kitten] [IANA #731918] SASL mechanism not listed Date: Mon, 24 Mar 2014 19:33:06 + From: Stephen Farrell stephen.farr...@cs.tcd.ie To: kit...@ietf.org kit...@ietf.org CC: iana-questi...@iana.org iana-questi...@iana.org Hiya, IANA were asked the following question a while back, but I dropped the ball;-) I'd appreciate your thoughts on the matter. I'm not quite sure which registries are meant exactly though. (I'll also forward to the oauth WG, but not cross-post) Thanks, S. start The following draft describes a SASL mechanism that is in use on GMail and should not therefore be allocated to another scheme unless we want bad things to happen. http://tools.ietf.org/id/draft-murchison-sasl-login-00.txt The strings XOAUTH and XOAUTH2 are also being used for a preliminary version of the OAUTH spec as well. The reason Google is using this particular mechanism rather than PLAIN is that it is the one that has the widest client support: http://www.fehcom.de/qmail/smtpauth.html So it would be a real disaster if this particular code point was re-issued. It would probably be a good idea if every registry had a list of 'dirty' code points that must not be reused because there are existing applications. end ___ Kitten mailing list kit...@ietf.org https://www.ietf.org/mailman/listinfo/kitten ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] TLS question from token revocation draft iesg evaluation
Hiya, This draft has a couple of minor changes needed as a result of IESG review (see [1]) but one question came up that I wanted to bring back to the WG to see what you think. Any good answer should be fine btw, this isn't a case of the insisting on stuff. The question is whether the WG think that the situation related to the mandatory-to-implement TLS version has changed since that was last discussed a couple of years ago. There have been changes in the implementation status of TLS1.2 since then, mainly driven by the discovery of weaknesses with some deployment choices for TLS1.0. So - should we stick with the TLS1.0 as MTI and TLS1.2 as a SHOULD implement or can we now safely bump up to TLS1.2 as MTI? And since its been a source of confusion here before, we're discussing what's mandatory to *implement* not what's mandatory to *use*. Thanks, S. PS: the other changes are mechanical so don't need to take up WG time but feel free to comment to the list, chairs, authors, me, ... whatever. [1] https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/ballot/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Use of Version Control Systems for Draft Editing
Hiya, On 05/13/2013 09:04 AM, Hannes Tschofenig wrote: Hi all, the OpenID Connect had gained some experience with using version control systems for editing specifications (and the use of issue trackers), see http://openid.bitbucket.org/. Based on a recent discussion in the IETF (among the working group chairs) I am wondering what your experience is with those tools and whether you see value in using these tools for document editing in the OAuth working group. Sounds like a fine plan if the wg want to try it. Only thing I'd note is that it means editors need to be *very* careful to bring discussion back to the wg list when that's needed, since you will likely get comments in the version control environment that are not cc'd to the wg list. (The IETF will be considering generic solutions for that, if you're interested get involved with the tools team.) In turn, I suspect that means that wg chairs need to make sure there's an editor who really gets when a change needs to be discussed on the list and when its ok to just fix a typo. The httpbis wg have some experience doing this btw and have hit that specific issue of comments being made on github but not the list. There's a recent thread [1] that ends with good advice from the wg chair. And in case someone asks, reasons why we need the wg list cc'd include open-ness and to be clear as to what's an IETF contribution. There're probably more but these are enough;-) Cheers, S. [1] http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0334.html Ciao Hannes ___ 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
Re: [OAUTH-WG] AD review of draft-ietf-oauth-revocation-06
Hi Torsten, That's great thanks. We're still after a mail from Marius ack'ing no IPR. Be nice to get that. I'll ask for IETF LC in a day or so in case the WG have anything to say, but a couple of follow-ups below that you can take as LC comments from me. On 04/15/2013 09:09 PM, Torsten Lodderstedt wrote: Hi Stephen, I just posted a new revision of the draft (http://tools.ietf.org/html/draft-ietf-oauth-revocation-07). I tried to address all the issues you raised (see below). Am 09.04.2013 19:27, schrieb Stephen Farrell: Hi, I've done my AD review of this draft. I have two quick questions I'd like to get answered before I start IETF LC. Depending on the answers maybe we should re-spin or just fire ahead, let's see... (1) 2.1: upon the return of the request isn't right is it? I think you mean the response at least. adjusted wording to upon receipt of an HTTP 200 response from the server And what about HTTP error handling? What if I get a 503 error? Is the client supposed to re-send ever? Don't you need to say? Added: If the server responds with HTTP status code 503, the client must assume the token still exists and may retry after a reasonable delay. The server may include a Retry-After header in the response to indicate how long the service is expected to be unavailable to the requesting client. I think it'd be worth looking at other HTTP consuming specs and maybe asking some folks about that. I suspect you might need to say 5xx rather than just 503 and reasonable is gonna set off transport area alarms bells probably. (2) 2.2: what's in the response body with a 200 response? If it doesn't matter please say so. Added: The content of the response body does not matter as all information is conveyed in the response code. I see from the write-up one author hasn't confirmed there are no IPR issues. I've sent a Marius a mail so hopefully we can sort that as we go. I also have the following nits that can be fixed (if need be) whenever the draft is next changed: - intro: app isn't really a great term to use, can you replace with something from 6479. Assuming you meant 6749 I changed it to application - section 2: the MAY include a query component is sort of dangling there, maybe it'd be better moved elsewhere? As Justin pointed out, the place is ok. I tried to improve wording a bit. The client requests the revocation of a particular token by making an HTTP POST request to the token revocation endpoint URL. This URL MAY include a query component. - section 2: MUST be obtained from a trustworthy source. might generate comment from IESG members who don't like using 2119 terms in ways that don't affect interoperability. (I'm fine with it fwiw, and have nearly cured 'em of that craze;-) Consider s/MUST/need to/ here. done - 2.1: ought there be a registry for token_type_hint values? It looks like maybe there ought be. Added registry in Section 5.1.2 I'd encourage WG participants to check that and see what they think. We can fix it (if needed) after IETF LC. Cheers, S. - 2.1: A client compliant with [RFC6749] must be prepared was that meant to be a 2119 MUST? yep, changed it. - section 6: maybe s/shall/need to/ in the last para done regards, Torsten. Cheers, S. ___ 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
Re: [OAUTH-WG] AD review of draft-ietf-oauth-revocation-06
Hi, I'm surprised there've been no responses. I thought there was more interest in this one. Ta, S. On 04/09/2013 06:27 PM, Stephen Farrell wrote: Hi, I've done my AD review of this draft. I have two quick questions I'd like to get answered before I start IETF LC. Depending on the answers maybe we should re-spin or just fire ahead, let's see... (1) 2.1: upon the return of the request isn't right is it? I think you mean the response at least. And what about HTTP error handling? What if I get a 503 error? Is the client supposed to re-send ever? Don't you need to say? (2) 2.2: what's in the response body with a 200 response? If it doesn't matter please say so. I see from the write-up one author hasn't confirmed there are no IPR issues. I've sent a Marius a mail so hopefully we can sort that as we go. I also have the following nits that can be fixed (if need be) whenever the draft is next changed: - intro: app isn't really a great term to use, can you replace with something from 6479. - section 2: the MAY include a query component is sort of dangling there, maybe it'd be better moved elsewhere? - section 2: MUST be obtained from a trustworthy source. might generate comment from IESG members who don't like using 2119 terms in ways that don't affect interoperability. (I'm fine with it fwiw, and have nearly cured 'em of that craze;-) Consider s/MUST/need to/ here. - 2.1: ought there be a registry for token_type_hint values? It looks like maybe there ought be. - 2.1: A client compliant with [RFC6749] must be prepared was that meant to be a 2119 MUST? - section 6: maybe s/shall/need to/ in the last para Cheers, S. ___ 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
Re: [OAUTH-WG] AD review of draft-ietf-oauth-revocation-06
Hiya, On 04/12/2013 10:03 PM, Justin Richer wrote: Hi Stephen, I didn't respond as I didn't have anything to add to your comments, but what little details I have are inline. Thanks:-) On 04/12/2013 04:53 PM, Stephen Farrell wrote: Hi, I'm surprised there've been no responses. I thought there was more interest in this one. Ta, S. On 04/09/2013 06:27 PM, Stephen Farrell wrote: Hi, I've done my AD review of this draft. I have two quick questions I'd like to get answered before I start IETF LC. Depending on the answers maybe we should re-spin or just fire ahead, let's see... (1) 2.1: upon the return of the request isn't right is it? I think you mean the response at least. And what about HTTP error handling? What if I get a 503 error? Is the client supposed to re-send ever? Don't you need to say? Should this read upon receipt of an HTTP 200 response from the server instead? Seems like it needs some fix anyway. I'll mark the draft as revised I-D needed. If there's a 503, the client can't assume the token is gone, but it also probably shouldn't try spamming the endpoint, either. So what is a client supposed to do if it gets a 503? (2) 2.2: what's in the response body with a 200 response? If it doesn't matter please say so. Doesn't matter. All information is conveyed in the response code. That'd be fine. But doesn't it need saying? Like I said the rest are nits. But to be clear: I think we (me and the WG) need to figure out the above before IETF LC starts. Cheers, S. I see from the write-up one author hasn't confirmed there are no IPR issues. I've sent a Marius a mail so hopefully we can sort that as we go. I also have the following nits that can be fixed (if need be) whenever the draft is next changed: - intro: app isn't really a great term to use, can you replace with something from 6479. app was chosen because the application to use here could be either the Client or the Resource Server in RFC6749, so neither is really the right fit. It's whoever's revoking the token. - section 2: the MAY include a query component is sort of dangling there, maybe it'd be better moved elsewhere? Don't see where else this could fit. Basically we're saying the endpoint URL can be defined as /endpoint?type=revoke just as easily as /revoke. - section 2: MUST be obtained from a trustworthy source. might generate comment from IESG members who don't like using 2119 terms in ways that don't affect interoperability. (I'm fine with it fwiw, and have nearly cured 'em of that craze;-) Consider s/MUST/need to/ here. WFM. - 2.1: ought there be a registry for token_type_hint values? It looks like maybe there ought be. I think a registry is overkill for this kind of thing, but I suppose it could be set up. It's meant to be a *hint* to the server as to what kind of token it is. If it does get set up, the Introspection draft will use it (if that ever can get either pulled into the WG or moved through as an individual submission). - 2.1: A client compliant with [RFC6749] must be prepared was that meant to be a 2119 MUST? This is informative, not normative. You could easily replace must with needs to here and get the same intended meaning, which is that tokens can disappear when you're not looking. - section 6: maybe s/shall/need to/ in the last para Same as above. Cheers, S. ___ 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] AD review of draft-ietf-oauth-revocation-06
Hi, I've done my AD review of this draft. I have two quick questions I'd like to get answered before I start IETF LC. Depending on the answers maybe we should re-spin or just fire ahead, let's see... (1) 2.1: upon the return of the request isn't right is it? I think you mean the response at least. And what about HTTP error handling? What if I get a 503 error? Is the client supposed to re-send ever? Don't you need to say? (2) 2.2: what's in the response body with a 200 response? If it doesn't matter please say so. I see from the write-up one author hasn't confirmed there are no IPR issues. I've sent a Marius a mail so hopefully we can sort that as we go. I also have the following nits that can be fixed (if need be) whenever the draft is next changed: - intro: app isn't really a great term to use, can you replace with something from 6479. - section 2: the MAY include a query component is sort of dangling there, maybe it'd be better moved elsewhere? - section 2: MUST be obtained from a trustworthy source. might generate comment from IESG members who don't like using 2119 terms in ways that don't affect interoperability. (I'm fine with it fwiw, and have nearly cured 'em of that craze;-) Consider s/MUST/need to/ here. - 2.1: ought there be a registry for token_type_hint values? It looks like maybe there ought be. - 2.1: A client compliant with [RFC6749] must be prepared was that meant to be a 2119 MUST? - section 6: maybe s/shall/need to/ in the last para Cheers, S. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Shepherd Writeup for draft-ietf-oauth-revocation-06
Thanks, If you don't see an AD review by the middle of next week please hassle me, Cheers, S. On 04/07/2013 03:45 PM, Hannes Tschofenig wrote: Dear Stephen, Dear IESG Secretary, here is my shepherd writeup for draft-ietf-oauth-revocation-06. Please proceed with the publication of this document. --- (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The RFC type being requested in Standards Track. The type is appropriate for this type of OAuth protocol extension. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the Action announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. The OAuth Token Revocation specification proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to cleanup security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant. Working Group Summary: The document experienced no particular problems in the working group. Document Quality: The document has been deployed by four companies, namely by Salesforce, Google, Deutsche Telekom, and MITRE. The working group reviewed and discussed the document extensively. Personnel: Hannes Tschofenig is the document shepherd. The responsible area director is Stephen Farrell. (3) Briefly describe the review of this document that was performed by the Document Shepherd. I have reviewed this version of the document and provided feedback to earlier versions of the draft. The document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? I have no concerns about the level of reviews. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No, there is no need for further reviews. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. I have no concerns regarding the document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Two of the three authors have confirmed that they are not aware of any IPRs. Marius Scurtescu so far has not responded to my mails. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR disclosures available for this document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The working group is in support of this document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) There has been no extreme discontent. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. ID nits have been verified. There is one reference ([portable-contacts]) that is not used in the document that has to be removed with the next draft update or by the RFC Editor. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The document does not contain
Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (3500)
This looks right to me (and I'm in a boring meeting processing errata:-) so I'm gonna mark it as verified. Please let me know if that's wrong. S On 02/26/2013 05:07 PM, RFC Errata System wrote: The following errata report has been submitted for RFC6749, The OAuth 2.0 Authorization Framework. -- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6749eid=3500 -- Type: Editorial Reported by: John Field johnp.fi...@emc.com Section: 4.1 Original Text - (E) The authorization server authenticates the client, validates the authorization code, and ensures that the redirection URI received matches the URI used to redirect the client in step (C). If valid, the authorization server responds back with an access token and, optionally, a refresh token. Corrected Text -- (E) The authorization server authenticates the client, validates the authorization code, and ensures that the redirection URI received matches the URI used to redirect (the resource owner's user-agent) to the client in step (C). If valid, the authorization server responds back with an access token and, optionally, a refresh token. Notes - The URI in question is the URI that was used to redirect the resource owner's user-agent back to the client to deliver the code. The original text in step (E) seems to say that this URI was used to redirect the client, but I think this is an ambiguous/imprecise use of the word client. It was not the OAuth client that was redirected using that URI, it was the resource owner's user-agent that was redirected, *to* the client. The parenthetical (the resource owner's user-agent) is more precise but may perhaps be too verbose. I think, at minimum, we must say the URI used to redirect *to* the client in step (C). Instructions: - This errata is currently posted as Reported. If necessary, please use Reply All to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -- RFC6749 (draft-ietf-oauth-v2-31) -- Title : The OAuth 2.0 Authorization Framework Publication Date: October 2012 Author(s) : D. Hardt, Ed. Category: PROPOSED STANDARD Source : Web Authorization Protocol Area: Security Stream : IETF Verifying Party : IESG ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Mandatory to implement
On 02/19/2013 02:58 PM, John Bradley wrote: Yes but that contradicts what Barry is appearing to ask for which is run time interoperability, by profile or configuration. 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. So you seem to be starting from a false dichotomy. S. While having code available in libraries is generally a good thing, I agree. That is likely not going to address all of Barry's issues. A number of us recommended that Assertions , JWT-assertions and SAML assertions go ahead together because they are interrelated. The chairs decided to send assertions on on it's own and it has been pushed back. That is not especialy surprising, because it is not intended to be complete and interoperable in a end to end system on its own. The question remains where to make what MTI. While it may be logical to make SAML support MTI in SAML assertions should every library supporting assertions have full SAML support even if the applications are only using JWT assertions? Where I think Barry and I agree is that we need to look at a group of documents that are intended to be used together for MTI rather than trying to overload Assertions which is only a small part of the whole. So where we may disagree is if requiring libraries to have code that systems don't use and is effectively dead, helps with overall interoperability or is mostly theatre. I suspect it is a continuum in that having the RS256 algorithm available in all the JWT assertion libraries lets applications using assertions choose to use it, but that doesn't guarantee all applications will, or allow a client to figure out if that algorithm is available for use. Hence my position that MTI without additional profiles/Discovery/negotiation is interoperability theatre if you are pretending it will make arbitrary OAuth deployments automatically work together. Regards John B. On 2013-02-19, at 4:22 AM, SM s...@resistor.net wrote: Hi John, At 12:54 18-02-2013, John Bradley wrote: That is where we get into the area Stephen Farrell has been raising about MTI not being required to deploy. The topic of mandatory to implement has been discussed previously in the working group. Stephen Farrell explained [1] what it meant. Barry Leiba explained what it meant. In my humble opinion a mandatory to implement feature is about having the code for the feature. If the code is out there it is easier to get what you want. Regards, -sm ___ 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
Re: [OAUTH-WG] oauth assertions plan
Hi Barry, I agree with you generally, but just on one point... On 02/18/2013 05:38 AM, Barry Leiba wrote: That's why I say that as I see it, it's not an issue of MTI. I do think there is an issue related to MTI that's affecting the discussion. Clearing up that issue won't by itself solve the interop problem but is, I think, needed as a part of doing that. The issue is that it seems to me that not everyone is clear that MTI != MUST-use. If some field with some syntax is MTI that means that everyone writing code has to be able to handle that field properly. It does not mean that everyone has to use that syntax. But if everyone's code supports handling that syntax, then we do enable better interoperability. So as you address Barry's good point, please do not conflate MTI with MUST-use since they are not the same. S. PS: Just in case: MTI == mandatory to implement ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] oauth assertions plan
Hi all, The OAuth assertion document has received DISCUSSes as you can see from the data tracker at [1]. I've been chatting with the chairs and the ADs with those DISCUSSes in the last few days. The main concern is that these documents do not sufficiently specify the functionality that is needed (MTI) in order to develop an interoperable implementation. This concern is, unfortunately, also applicable to the two assertion instance documents, the JWT (draft-ietf-oauth-jwt-bearer) and the SAML (draft-ietf-oauth-saml2-bearer) documents. I've therefore decided to send the assertion document back to the working group and to recommend to the group to resubmit them for publication once these blocking DISCUSSes have been addressed satisfactory. I think this will need some consideration of both the assertions framework and the saml/jwt drafts. (Probably submitting two or three of those at once makes better sense anyway.) To help resolve this we're planning to meet at lunch time on the Monday of the IETF just before the oauth session. The goal of that chat is to try to figure out what'll need doing to get these documents ready, so that that plan can be presented as a semi-worked out proposal at the oauth session later that day. I'd like to have the document editors/authors, chairs and discussing ADs there if possible. (I'll send details.) If someone else really needs to be there, let me know but I think starting with the smaller group will be more tractable. If everyone thinks we need to just work it out at the WG session that's fine and we can skip the lunchtime meeting, but I'd say we're likely to end up in the same place but take longer. However, if this can be sorted on the list beforehand that's much better of course, so please do try to do that starting now. (That is, let's not start by quibbling about process and lunchtime meetings but by discussing the DISCUSSes:-) Regards, Stephen. [1] http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ballot/. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] oauth assertions plan
In some off-list mail between Mike and I, he said: Was TCP a bad idea because it didn't have MTI port numbers? Would it have improved TCP to add an MTI port or two? To which I responded: Ports are MTI for TCP. [1] They are 16 bit values with a well-defined test for equality and a little bit more structure/IANA stuff. We agreed it'd be useful to bring this to the list since it maybe captures the disconnect. I'm not sure I quite get it but I think Mike means that no particular port number (or the associated protocol) needs to be listened for by all TCP stacks. That's correct, but nothing to do with TCP interop. Port numbers do need to be specified by all TCP packets or those are malformed and all TCP stacks need to know how to compare those and probably more subtleties but support for port numbers is definitely not optional - its mandatory. Cheers, S. [1] http://tools.ietf.org/html/rfc793#section-2.7 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today
Hi Hannes, On 01/19/2013 04:19 PM, Hannes Tschofenig wrote: Thanks for the feedback. I see that a couple of you have decided to go with option 2. Yep, looks like it. I've moved this back to Feb 7 so the discussion doesn't need to be rushed. S. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today
Hiya, So I'll take the lack of further discussion about this an meaning that the wg want this to shoot ahead. I'll put this in as an RFC editor note for the draft. Cheers, S. On 01/18/2013 12:04 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: Hi all, As you have seen on the list (see http://www.ietf.org/mail-archive/web/oauth/current/msg10526.html) I had a chat with Mike about how to address my comment for the assertion draft and Mike kindly provided his text proposal (see http://www.ietf.org/mail-archive/web/oauth/current/msg10529.html). I have used his text as input and extended it a bit. Here is the updated text. Operational Considerations and Interoperability Expectations This specification defines a framework for using assertions with OAuth 2.0. However, as an abstract framework on its own, this specification is not sufficient to produce interoperable implementations. Two other specifications that instantiate this framework have been developed, one uses SAML 2.0-based assertions and is described in [I-D.ietf-oauth-saml2-bearer] and the second builds on JSON Web Tokens (JWTs) and can be found in [I-D.ietf-oauth-jwt-bearer]. These two instantiations provide additional details about the assertion encoding and processing rules for those interested to implement and deploy assertions with OAuth 2.0. However, even with these instance documents an interoperable implementation is not possible since for a specific deployment environment (within a trust framework or circle of trust, as it is sometimes called) agreements about acceptable values for various fields in the specification have to be agreed upon. For example, the audience field needs to be populated by the entity that generates the assertion with a specific value and that value may hold identifiers of different types (for example, a URL, an IP address, an FQDN) and the entity receiving and verifying the assertion must compare the value in the audience field with other information it may obtain from the request and/or with locally available information. Since the abstract framework nor the instance documents provide sufficient information about the syntax, the semantic and the comparison operation of the audience field additional profiling in further specifications is needed for an interoperable implementation. This additional profiling is not only needed for the audience field but also for other fields as well. This framework was designed with the expectation that additional specifications will fill this gap for deployment-specific environments. You have the choice: 1. take this as-is if you want the assertion draft (draft-ietf-oauth-assertions ) on the Jan 24 IESG telechat. There is no normative text in the writeup; it is rather a clarification. 2. discuss it if need be, and draft-ietf-oauth-assertions will be on the Feb 7 telechat (if the discussion is done by Feb 1) 1 or 2 needs to be chosen today. Ciao Hannes PS: FYI - draft-ietf-oauth-saml2-bearer and draft-ietf-oauth-jwt-bearer are not yet on the telechat agenda. ___ 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
Re: [OAUTH-WG] draft-ietf-oauth-assertions-09
Hi, Since we thought we were done with it, I put this document on the IESG telechat agenda for Jan 24. Hannes' question however looks like its a real one that needs an answer. I'd appreciate it if the WG could figure out if there's any change needed and either make that change in the next week, or else tell me to take the draft off the telechat agenda for now. If discussion doesn't happen, or happens but doesn't reach a conclusion, then I'll take the draft off the agenda in a week's time and we can sort out if any changes are needed later. The reason why now+1-week matters, is that that's when IESG members tend to do their reviews and having 'em all review a moving target isn't a good plan. Thanks, S. On 01/11/2013 08:18 AM, Hannes Tschofenig wrote: Hi guys, Thanks for updating the assertion document and for incorporating the comments received on the mailing list. There is only one issue that caught my attention. You changed the description of the audience element to the following text (in version -09 of http://tools.ietf.org/html/draft-ietf-oauth-assertions-09): Audience A value that identifies the parties intended to process the assertion. An audience value MAY be the URL of the Token Endpoint as defined in Section 3.2 of OAuth 2.0 [RFC6749]. Since the value in the audience field is used to by the authorization server in a comparison operation (see Section 5.2) I believe the current text will lead to interoperability problems. Not only is the comparision operation unspecified but even the value that is contained in the field is left open. The RFC 2119 MAY does not really give a lot of hints of what should be put in there. Without having a clear description of what identifier is contained in this field and how the comparison works it is either possible that a legitimate client is rejected by the authorization server (which is annoying) or an assertion with an incorrect assertion is accepted (which is a security problem). Btw, the same issue can also be seen in http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04, http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15 and in a more generic form also in the JWT (Section 4.1.3 of http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; aud claim). From the description in the JWT document I was not quite sure whether the ability to carry an array of case sensitive strings for that field is also allowed in any of the assertion documents. Note that there are two documents that provide input to this problem space, namely: http://tools.ietf.org/html/rfc6125 http://tools.ietf.org/html/draft-iab-identifier-comparison-07 So, I would suggest to decide what type of identifier goes into this field and then to point to a document that illustrates how the comparison operation would look like. Possible identifiers are domain names, IP addresses, URIs, etc. Just as an example from RFC 6125 would you allow a wildcard match (like *.example.com) or only an equality match? Would www.example.com be the same as example.com if they resolve to the same IP address(es)? Ciao Hannes ___ 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
Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (3446)
On 01/09/2013 11:02 PM, Derek Atkins wrote: Barry Leiba barryle...@computer.org writes: 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. Yep, I suggested that same change in a private email to Stephen, so I would prefer this modification. Ok, assuming nobody objects I'll verify this that way tomorrow. Cheers, S Barry -derek ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Writeup for Assertion Framework for OAuth 2.0 draft-ietf-oauth-assertions-07
Hi Hannes, all, Sorry to have been slow with the AD review here. I've only a few comments (below) that can be handled as IETF LC comments. Any changes as a result of the recent thread on the definition of Issuer can also be done then. Unless someone tells me to hold off for a new version, I'll request IETF LC for this later today. Thanks, S. section 3, 2nd para: this says that an Issuer signs assertions, I think you do include MACing as well, right? If so, better to say so, so maybe s/signs/integrity protects/ would be better? If you are going to stick with sign to mean either digital signature or MAC, then please say so explicitly. s3, 3rd para: if assertions MUST be signed, then MUST they also be verified by RPs? I think you should say. 5.2: The Audience SHOULD be the URL of the Authorization Server's Token Endpoint - are there any issues there with URL comparisons that need to be specified here? Or is that something to do for a specific type of assertion? Either way, might be good to say. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-threatmodel-07.txt
Thanks, Since this is on the Aug 30 telechat let's not have any further changes without a chair/AD asking. Ta, S On 16 Aug 2012, at 18:19, Torsten Lodderstedt tors...@lodderstedt.net wrote: Hi all, the new revision covers token substitution, which has been added to the core spec lately. Additionally, it describes a similar attack on the code flow, which is prevented by forcing the authorization server to validate that an authorization code had been issued to the calling client. We also made the references to core and bearer spec normative. regards, Torsten. Am 16.08.2012 19:14, schrieb internet-dra...@ietf.org: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Threat Model and Security Considerations Author(s) : Torsten Lodderstedt Mark McGloin Phil Hunt Filename: draft-ietf-oauth-v2-threatmodel-07.txt Pages : 70 Date: 2012-08-16 Abstract: This document gives additional security considerations for OAuth, beyond those in the OAuth specification, based on a comprehensive threat model for the OAuth 2.0 Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-threatmodel-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ 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
Re: [OAUTH-WG] AD review of draft-ietf-oauth-threatmodel-05
Since I'm told this is now ready, I've put this on the August 30th telechat. Note there is an RFC editor note [1] calling for making the reference to oauth core normative. S. [1] https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel/writeup/ On 06/28/2012 04:21 AM, Phil Hunt wrote: Stephen One more threat has come up in the core spec that is being looked at. As Torsten is heading out on vacation I have agreed to augment if needed with any supplementary text to the threat model. Will keep you informed. Phil On 2012-06-27, at 17:17, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: Hiya, Great. I've asked for IETF LC to start. I'll go through the changes below during that in case there's some more follow up. Thanks, S. On 06/27/2012 07:03 PM, Torsten Lodderstedt wrote: Hi Stephen, I just submitted a new revision of the security document incorporating your review comments. Please find answers to your comments below. Thank you again for your detailed review. You helped us to significantly improve the document's quality. best regards, Torsten. Am 28.05.2012 20:34, schrieb Stephen Farrell: Hi all, I've gotten the publication request for oauth-threatmodel so here's my AD review of -05. Its quite a read (and a good one) but I've a bunch of questions. Some of these will need fixing I suspect but a lot are ok to fix later after IETF LC, depending on whether the authors want to re-spin it before then or not. But I'd like to at least see reactions to the questions before I start IETF LC. Although there are many many nits and typos, those don't actually make the document unreadable so though I'd prefer to see 'em fixed now, I'm ok with that happening later if its a problem to get it all done now. If you want to argue for going ahead with IETF LC now please do so, but I suspect that this might need a revised ID to fix at least a couple of the points raised below. If nobody does argue to go ahead now, I'll mark it as revised ID needed, but first let's see what the answers are to the questions. Cheers, S. (1) s/RFC1750/RFC4086/ is needed as noted in the write-up. done (2) You don't say anything about the probability of occurrence of the various threats. I realise that you can't be precise but it seems wrong to say nothing. Would it be worth at least saying that that's not done here and that readers of this document need to do their own risk analysis including that aspect? That's correct - I added the following paragraph to the introduction: Note: This document cannot assess the probability nor the risk associated with a particular threat because those aspects strongly depend on the particular application and deployment OAuth is used to protect. Similar, impacts are given on a rather abstract level. But the information given here may serve as a foundation for deployment-specific threat models. Implementors may refine and detail the abstract threat model in order to account for the specific properties of their deployment and to come up with a risk analysis. (3) Many deployments will use TLS accelerators. That means that TLS isn't fully e2e, and that opens up some (mainly) insider attacks or attacks that can be launched from within a compromised DMZ, but from outside the server applications. Does that need a mention somewhere? (I've seen systems like that deployed and a lot could go wrong from the inside, so I think this is a real threat.) I added another paragraph to section 5.1.1: Note: this document assumes end-to-end TLS protected connections between the respective protocol entities. Deployments deviating from this assumption by offloading TLS in between (e.g. on the data center edge) must refine this threat model in order to account for the additional (mainly insider) threat this may cause. (4) Could you use just one of client identity or client identifier consistently? I'd much prefer the latter, which has also been the outcome of various discussions on this topic elsewhere. For example you say revocation of such an identity at the end of p13, and that's a potential rathole, better to say revocation of the rights associated with a client identifier or similar I think. And similar changes throughout. Replaced client identity by client identifier in most places and incorporated your proposed text (5) 4.4.2.2: Here you recommend native applications should use an embedded browser, but earlier you said that was a bad idea. I think you need to be consistent or else provide more about when its ok to embed and when its not. Did I misread it or does that need a change? removed 3rd bullet as native apps should use code flow We also removed the 1st bullet in 4.4.1.9 (6) 4.4.3.1: This calls for obfuscation of passwords in logs. I think you ought be stronger there and call for strong encryption of passwords wherever they are stored, be that logs or DBs or whatever. Would'nt
Re: [OAUTH-WG] oauth-bearer and rfc 2617/httpbis authentication framework
Hiya, On 07/23/2012 08:56 AM, Julian Reschke wrote: On 2012-07-23 00:33, Stephen Farrell wrote: Hi all, I'd like to check that some recent minor changes to this document [1] don't cause technical or process-grief. The version [2] of the oauth bearer draft that underwent IETF LC and IESG evaluation had a normative dependency on the httpbis wg's authentication framework. [3] After resolving IESG discuss positions the authors and wg chairs felt that it would be better to replace the normative reference to the httpbis wg draft [3] with one to RFC 2617 [4] so that the OAuth drafts wouldn't be held in the RFC editor queue waiting on the httpbis wg to get done. I believe there is no impact on interop resulting from this change but there has been some disagreement about making it and how it was made. After some offlist discussion I think we now have an RFC editor note [5] that means that the current scheme of referring to RFC 2617 is ok. ... Quoting: NEW: The Authorization header for this scheme follows the usage of the Basic scheme [RFC2617]. Note that, as with Basic, this is compatible with the the general authentication framework being developed for HTTP 1.1 [I-D.ietf-httpbis-p7-auth], though does not follow the preferred practice outlined therein in order to reflect existing deployments. The syntax for Bearer credentials is as follows: That helps, but it still hides the fact that the syntax is not compatible with the RFC 2617 framework. hides isn't a goal:-) Also, s/header/header field/ Proposal: The syntax of the Authorization header field for this scheme follows the usage of the Basic scheme defined in Section 2 of [RFC2617]. Note that, as with Basic, it does not conform to the generic syntax defined in Section 1.2 of [RFC2617], but that it is compatible with the the general authentication framework being developed for HTTP 1.1 [I-D.ietf-httpbis-p7-auth], although it does not follow the preferred practice outlined therein in order to reflect existing deployments. The syntax for Bearer credentials is as follows: ... That looks better. I've updated the RFC editor note to use your text. Thanks, S. Best regards, Julian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] oauth-bearer and rfc 2617/httpbis authentication framework
Hi all, I'd like to check that some recent minor changes to this document [1] don't cause technical or process-grief. The version [2] of the oauth bearer draft that underwent IETF LC and IESG evaluation had a normative dependency on the httpbis wg's authentication framework. [3] After resolving IESG discuss positions the authors and wg chairs felt that it would be better to replace the normative reference to the httpbis wg draft [3] with one to RFC 2617 [4] so that the OAuth drafts wouldn't be held in the RFC editor queue waiting on the httpbis wg to get done. I believe there is no impact on interop resulting from this change but there has been some disagreement about making it and how it was made. After some offlist discussion I think we now have an RFC editor note [5] that means that the current scheme of referring to RFC 2617 is ok. If there are no problems with this in the next week I'll move the document [1] along as-is. Thanks, Stephen. [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-18 [3] http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth [4] http://tools.ietf.org/html/rfc2617 [5] https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/writeup/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] draft-ietf-oauth-urbn-sub-ns
Hi, This draft was approved on yesterday's IESG telechat. Before sending it off to the RFC editor would you take a look at the comments [1] and let me know if there are any changes worth making. If they're tiny but worth doing, (which they probably are) I can put them in as an RFC editor note, so there's no need for a new version. (And you couldn't post one anyway right now since we're in the pre-meeting blackout phase.) And of course, sooner is better than later... Thanks, S. [1] https://datatracker.ietf.org/doc/draft-ietf-oauth-urn-sub-ns/ballot/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-22.txt
Folks. Please don't develop any new revisions for these documents right now. I know you can't officially post 'em anyway, but I don't want us to get tempted to roll new versions handling unrelated comments. (Alexey's comments are not unrelated.) I'd like to handle any tweaks needed as RFC editor notes if possible. S On 07/17/2012 12:04 PM, Alexey Melnikov wrote: I am still Ok with -22, but I have 1 new comment raised by introduction of the base64 ABNF non terminal: I think it would be worth adding a comment for b64token that points to the base64 RFC. The current ABNF is too permissive (arbitrary number of = allowed at the end) and there are enough broken base64 parsers around (parsers that ignore everything after a =, parsers that support arbitrary number of = at the end, etc.), so we shouldn't encourage creation of new ones. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-ietf-oauth-v2-30 and draft-ietf-oauth-v2-bearer-22
Hi Hannes, That's great thanks. And thanks all for the good work. Since there've been a good few changes and a bit of time has elapsed I'll give the other IESG members who previously commented on these a few days to check if the changes are ok, and then I can shoot 'em along. Cheers, S. PS: A few days probably means a week really, since there's a packed telechat agenda this week of about 500 wonderful pages of I-D, so I wouldn't expect folks to have much chance to look at this before Friday;-) On 07/16/2012 06:39 PM, Hannes Tschofenig wrote: Hi Stephen, I had just gotten the confirmation from the authors of draft-ietf-oauth-v2-30 and draft-ietf-oauth-v2-bearer-22 that all remaining open issues had been closed. The evaluation record also shows happy IESG members. Please advance the status of these two documents. Ciao Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD review of draft-ietf-oauth-threatmodel-05
Hiya, Great. I've asked for IETF LC to start. I'll go through the changes below during that in case there's some more follow up. Thanks, S. On 06/27/2012 07:03 PM, Torsten Lodderstedt wrote: Hi Stephen, I just submitted a new revision of the security document incorporating your review comments. Please find answers to your comments below. Thank you again for your detailed review. You helped us to significantly improve the document's quality. best regards, Torsten. Am 28.05.2012 20:34, schrieb Stephen Farrell: Hi all, I've gotten the publication request for oauth-threatmodel so here's my AD review of -05. Its quite a read (and a good one) but I've a bunch of questions. Some of these will need fixing I suspect but a lot are ok to fix later after IETF LC, depending on whether the authors want to re-spin it before then or not. But I'd like to at least see reactions to the questions before I start IETF LC. Although there are many many nits and typos, those don't actually make the document unreadable so though I'd prefer to see 'em fixed now, I'm ok with that happening later if its a problem to get it all done now. If you want to argue for going ahead with IETF LC now please do so, but I suspect that this might need a revised ID to fix at least a couple of the points raised below. If nobody does argue to go ahead now, I'll mark it as revised ID needed, but first let's see what the answers are to the questions. Cheers, S. (1) s/RFC1750/RFC4086/ is needed as noted in the write-up. done (2) You don't say anything about the probability of occurrence of the various threats. I realise that you can't be precise but it seems wrong to say nothing. Would it be worth at least saying that that's not done here and that readers of this document need to do their own risk analysis including that aspect? That's correct - I added the following paragraph to the introduction: Note: This document cannot assess the probability nor the risk associated with a particular threat because those aspects strongly depend on the particular application and deployment OAuth is used to protect. Similar, impacts are given on a rather abstract level. But the information given here may serve as a foundation for deployment-specific threat models. Implementors may refine and detail the abstract threat model in order to account for the specific properties of their deployment and to come up with a risk analysis. (3) Many deployments will use TLS accelerators. That means that TLS isn't fully e2e, and that opens up some (mainly) insider attacks or attacks that can be launched from within a compromised DMZ, but from outside the server applications. Does that need a mention somewhere? (I've seen systems like that deployed and a lot could go wrong from the inside, so I think this is a real threat.) I added another paragraph to section 5.1.1: Note: this document assumes end-to-end TLS protected connections between the respective protocol entities. Deployments deviating from this assumption by offloading TLS in between (e.g. on the data center edge) must refine this threat model in order to account for the additional (mainly insider) threat this may cause. (4) Could you use just one of client identity or client identifier consistently? I'd much prefer the latter, which has also been the outcome of various discussions on this topic elsewhere. For example you say revocation of such an identity at the end of p13, and that's a potential rathole, better to say revocation of the rights associated with a client identifier or similar I think. And similar changes throughout. Replaced client identity by client identifier in most places and incorporated your proposed text (5) 4.4.2.2: Here you recommend native applications should use an embedded browser, but earlier you said that was a bad idea. I think you need to be consistent or else provide more about when its ok to embed and when its not. Did I misread it or does that need a change? removed 3rd bullet as native apps should use code flow We also removed the 1st bullet in 4.4.1.9 (6) 4.4.3.1: This calls for obfuscation of passwords in logs. I think you ought be stronger there and call for strong encryption of passwords wherever they are stored, be that logs or DBs or whatever. Would'nt that be reasonable? This section is about preventing accidential exposure by the client. I think encryption is not appropriate here since the password is entered in the clear by the user. I added the advice to encrypt credentials as alternative means to salted hashes to 5.1.4.1.3. (7) 4.6.4: 1st countermeasure: I don't think you mean address here (in the sense of an IP address, which is what that means) but rather the domain name or FQDN or URL. In any case, you need to say what is meant clearly. (Also in 5.1.5.6 and elsewhere when you use the term address.) replaced address in most cases
Re: [OAUTH-WG] AD review of draft-ietf-oauth-urn-sub-ns-02
On 06/20/2012 05:14 PM, Mike Jones wrote: Per your question (5) Stephen, possibly see the registrations in http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-12#section-6. Authors, maybe using one of these as an example would help? Thanks Mike, that answers the question. I can't see IANA picking that id part but we can ask if the WG want to ask. S. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] FW: Pete Resnick's Discuss on draft-ietf-oauth-v2-bearer-20: (with DISCUSS and COMMENT)
Hi Mike, As you noted this is under way. When I mailed tlr I asked for two weeks from the 13th, which co-incides with the end of the IETF LC caused by the IPR declaration, so it should be fine. Cheers, S. On 06/18/2012 07:08 PM, Mike Jones wrote: Hi Stephen, Pete is holding his DISCUSS on Bearer open until the current text on the URI query parameter http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-20#section-2.3 receives W3C review. Can you try to have that review happen this week, hopefully finishing sometime next week? I'm cc:'ing Mark in his role as W3C liaison. Thanks again, -- Mike -Original Message- From: Pete Resnick [mailto:presn...@qualcomm.com] Sent: Tuesday, June 12, 2012 1:40 PM To: The IESG Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-v2-bea...@tools.ietf.org Subject: Pete Resnick's Discuss on draft-ietf-oauth-v2-bearer-20: (with DISCUSS and COMMENT) Pete Resnick has entered the following ballot position for draft-ietf-oauth-v2-bearer-20: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. -- DISCUSS: -- Mark Nottingham's Applications Area review http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03805.html identified the issue of URI query parameters in section 2.3: URI query parameters are normally locally scoped. In this document, a query parameter (access_token) is being defined as applying to all URIs. This is (relatively) novel. A few people in the HTTP community (including Mark) have expressed concerns. (See also http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04932.html and http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04933.html from the apps-discuss archive.) This issue should probably be further reviewed by W3C folks. I'm holding the DISCUSS as per Stephen to make sure we get that review. -- COMMENT: -- In section 2.3, the new last paragraph starts: This method is included to document current use; its use is NOT RECOMMENDED... NOT RECOMMENDED is not defined by 2119, and the language is redundant with the previous paragraph and potentially confusing. I suggest replacing it with simply: This method is included to document current use; as indicated in the previous paragraph, the use of this method is not recommended... BTW: The SHOULD NOT unless... in the previous paragraph is itself redundant. I think you mean MUST NOT unless SHOULD NOT *means* MUST NOT unless you understand what you're doing. Mark Nottingham's Applications Area review http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03805.html has a couple of comments that I think deserve further reply: * Section 1: Introduction The introduction explains oauth, but it doesn't fully explain the relationship of this specification to OAuth 2.0. E.g., can it be used independently from the rest of OAuth? Likewise, the overview (section 1.3) seems more specific to the OAuth specification than this document. As I read it, this mechanism could be used for ANY bearer token, not just one generated through OAuth flows. If it is indeed more general, I'd recommend minimising the discussion of OAuth, perhaps even removing it from the document title. I agree that the title would be better simply as HTTP Bearer Tokens, and then explain in the Abstract and Intro that the motivation and intended use of these Bearer Tokens is the OAuth 2.0 specification. A possibly useful side effect of this change might be that you can make OAuth 2.0 an informative (as against a normative) reference, and that these things could be reused for other purposes in the future. Not a huge deal, but I (like Mark) was unconvinced that the reference to OAuth in the title was necessary. * Section 3 The WWW-Authenticate Response Header Field The difference between a realm and a scope is not explained. Are the functionally equivalent, just a single value vs. a list? Some text, and probably an example, might help explain this a bit better. One of his comments asked for some additional review. I don't have a personal opinion whether this is needed, but perhaps you should pursue this: * General The draft currently doesn't mention whether
[OAUTH-WG] 2nd IETF LC on oauth bearer document
Hi all, Just so's you know, I've requested the additional IETF LC on the oauth bearer draft. This is because a reviewer after the previous IETF LC and after the IESG telechat noticed some IPR and did the right thing. I think we're close enough to done that folks can make their evaluations of what they think about the IPR declaration. If you disagree, that's a fine IETF LC comment:-) The IETF LC mail should pop out later today. Thanks, Stephen. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD review of draft-ietf-oauth-threatmodel-05
On 06/03/2012 08:57 AM, Torsten Lodderstedt wrote: Hi Stephen, thank you very much for your review. Having scanned through your comments, I think the document would definitely benefit from incorporating them into a new revision. We will start working on it now, but I can't tell you how long it will take (due to daytime job load). Sure. With 3 authors and most of the comments only needing trivial fixes, I'd hope that's not too long a job. (Or, if it is, maybe ask the chairs to try find more help.) Cheers, S. best regards, Torsten. Am 28.05.2012 20:34, schrieb Stephen Farrell: Hi all, I've gotten the publication request for oauth-threatmodel so here's my AD review of -05. Its quite a read (and a good one) but I've a bunch of questions. Some of these will need fixing I suspect but a lot are ok to fix later after IETF LC, depending on whether the authors want to re-spin it before then or not. But I'd like to at least see reactions to the questions before I start IETF LC. Although there are many many nits and typos, those don't actually make the document unreadable so though I'd prefer to see 'em fixed now, I'm ok with that happening later if its a problem to get it all done now. If you want to argue for going ahead with IETF LC now please do so, but I suspect that this might need a revised ID to fix at least a couple of the points raised below. If nobody does argue to go ahead now, I'll mark it as revised ID needed, but first let's see what the answers are to the questions. Cheers, S. (1) s/RFC1750/RFC4086/ is needed as noted in the write-up. (2) You don't say anything about the probability of occurrence of the various threats. I realise that you can't be precise but it seems wrong to say nothing. Would it be worth at least saying that that's not done here and that readers of this document need to do their own risk analysis including that aspect? (3) Many deployments will use TLS accelerators. That means that TLS isn't fully e2e, and that opens up some (mainly) insider attacks or attacks that can be launched from within a compromised DMZ, but from outside the server applications. Does that need a mention somewhere? (I've seen systems like that deployed and a lot could go wrong from the inside, so I think this is a real threat.) (4) Could you use just one of client identity or client identifier consistently? I'd much prefer the latter, which has also been the outcome of various discussions on this topic elsewhere. For example you say revocation of such an identity at the end of p13, and that's a potential rathole, better to say revocation of the rights associated with a client identifier or similar I think. And similar changes throughout. (5) 4.4.2.2: Here you recommend native applications should use an embedded browser, but earlier you said that was a bad idea. I think you need to be consistent or else provide more about when its ok to embed and when its not. Did I misread it or does that need a change? (6) 4.4.3.1: This calls for obfuscation of passwords in logs. I think you ought be stronger there and call for strong encryption of passwords wherever they are stored, be that logs or DBs or whatever. Would'nt that be reasonable? (7) 4.6.4: 1st countermeasure: I don't think you mean address here (in the sense of an IP address, which is what that means) but rather the domain name or FQDN or URL. In any case, you need to say what is meant clearly. (Also in 5.1.5.6 and elsewhere when you use the term address.) (8) 4.6.6: You say to use Cache-Control, but don't say how. Is more needed really? Maybe there's a good document you could reference for that? (I'm not suggesting you add a lecture on caching btw:-) (9) 5.1.1: needs a reference to RFC 5246 (and better to just say TLS and not say SSL, at least for me :-) (10) 5.1.1: needs a reference to whatever you mean by VPN since there are many types of VPN. I assume you mean an IPsec VPN? But even if not, saying more would be good. (11) 5.1.2: needs a reference to RFC 5280 and/or RFC 6125 and/or RFC 2818. Bascially, you need to say how this is done (by reference). (12) 5.1.4.1: Isn't there some good reference you can give here? (Having said that, I'd have to go look myself, but I'd maybe start with owasp or sans.) (13) 5.1.4.2.2: if p(collision) should be=2^(-160) then what's the point of saying it ought be= 2^(-128)? Also if sha-1 were perfect, then the 160 bits output would really have a collision probability of about 2^(-80) with many many tokens, but not 2^(-160). I think you need to fix something there. Perhaps you're really saying that all high-entropy secrets should be=128 bits long and constructed with a good (P)RNG? If so, saying so more clearly would be better. Not everyone will get the collision probability way of saying that even when its properly stated. (This text is also repeated, be better if you just said this once I think
Re: [OAUTH-WG] Internal WG Review: Recharter of Web Authorization Protocol (oauth)
Hi, There's been a bit of IESG comment on the proposed new charter resulting in a few editorial changes. So just in case, the text below is what I'd like to propose for approval on Thursday. Let me know if there's anything substantively wrong here, in which case, we'll probably want to re-spin the text and I'll put it back for consideration on the following IESG meeting (another two weeks). Thanks, Stephen. -- Web Authorization Protocol (oauth) -- Current Status: Active Last updated: 2012-05-03 Chairs: Hannes Tschofenig hannes.tschofe...@gmx.net Derek Atkins de...@ihtfp.com Security Area Directors: Stephen Farrell stephen.farr...@cs.tcd.ie Sean Turner turn...@ieca.com Security Area Advisor: Stephen Farrell stephen.farr...@cs.tcd.ie Technical Advisor: Peter Saint-Andre stpe...@stpeter.im Mailing Lists: Address: oauth@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/oauth Archive: http://www.ietf.org/mail-archive/web/oauth/ Description of Working Group: The Web Authorization (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account and without having the user sharing his or her photo-sharing sites' long-term credential with the printing site. The OAuth protocol suite encompasses * a procedure for allowing a client to discover a authorization server, * a protocol for obtaining authorization tokens from an authorization server with the resource owner's consent, * protocols for presenting these authorization tokens to protected resources for access to a resource, and * consequently for sharing data in a security and privacy respective way. The working group also developed security schemes for presenting authorization tokens to access a protected resource. This led to the publication of the bearer token, as well as work that remains to be completed on message authentication code (MAC) access authentication and SAML assertions to interwork with existing identity management solutions. The working group will complete those remaining documents, and will also complete documentation of the OAuth threat model that was started under the previous charter. The ongoing standardization effort within the OAuth working group will focus on enhancing interoperability of OAuth deployments. A standard for a token revocation service, which can be separated from the existing web tokens to the token repertoire will enable wider deployment of OAuth. Extended documentation of OAuth use cases will enhance the understanding of the OAuth framework and provide assistance to implementors. And dynamic client registration will make it easier to broadly deploy OAuth clients (performing services to users). Goals and Milestones Done Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item Done Submit 'HTTP Authentication: MAC Authentication' as a working group item Done Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard Done Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard May 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard May 2012 Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard May 2012 Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard May 2012 Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC Dec. 2012 Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard Aug. 2012 Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/] Nov. 2012 Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://tools.ietf.org/html/draft-jones-json-web-token] Nov. 2012 Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer] Dec. 2012 Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC [Starting point
Re: [OAUTH-WG] Internal WG Review: Recharter of Web Authorization Protocol (oauth)
Hi Mike, On 05/09/2012 06:41 PM, Mike Jones wrote: Looks pretty good to me. I might consider adding a sentence in the paragraph that motivates the new work items (that starts with The ongoing standardization effort) to motivate the JWT work items. For instance Having a standard JSON-based assertion format and a profile for using it with OAuth will both improve interoperability among selected OAuth deployments and facilitate deployments. (All the other new work items are already motivated in that paragraph.) I'm not sufficiently familiar with the current state of play to include JSON-based so I've left that out. Typo: Change a authorization to an authorization. Ta, S. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Stephen Farrell Sent: Wednesday, May 09, 2012 7:27 AM To: oauth-cha...@tools.ietf.org Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Internal WG Review: Recharter of Web Authorization Protocol (oauth) Hi, There's been a bit of IESG comment on the proposed new charter resulting in a few editorial changes. So just in case, the text below is what I'd like to propose for approval on Thursday. Let me know if there's anything substantively wrong here, in which case, we'll probably want to re-spin the text and I'll put it back for consideration on the following IESG meeting (another two weeks). Thanks, Stephen. -- Web Authorization Protocol (oauth) -- Current Status: Active Last updated: 2012-05-03 Chairs: Hannes Tschofenig hannes.tschofe...@gmx.net Derek Atkins de...@ihtfp.com Security Area Directors: Stephen Farrell stephen.farr...@cs.tcd.ie Sean Turner turn...@ieca.com Security Area Advisor: Stephen Farrell stephen.farr...@cs.tcd.ie Technical Advisor: Peter Saint-Andre stpe...@stpeter.im Mailing Lists: Address: oauth@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/oauth Archive: http://www.ietf.org/mail-archive/web/oauth/ Description of Working Group: The Web Authorization (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account and without having the user sharing his or her photo-sharing sites' long-term credential with the printing site. The OAuth protocol suite encompasses * a procedure for allowing a client to discover a authorization server, * a protocol for obtaining authorization tokens from an authorization server with the resource owner's consent, * protocols for presenting these authorization tokens to protected resources for access to a resource, and * consequently for sharing data in a security and privacy respective way. The working group also developed security schemes for presenting authorization tokens to access a protected resource. This led to the publication of the bearer token, as well as work that remains to be completed on message authentication code (MAC) access authentication and SAML assertions to interwork with existing identity management solutions. The working group will complete those remaining documents, and will also complete documentation of the OAuth threat model that was started under the previous charter. The ongoing standardization effort within the OAuth working group will focus on enhancing interoperability of OAuth deployments. A standard for a token revocation service, which can be separated from the existing web tokens to the token repertoire will enable wider deployment of OAuth. Extended documentation of OAuth use cases will enhance the understanding of the OAuth framework and provide assistance to implementors. And dynamic client registration will make it easier to broadly deploy OAuth clients (performing services to users). Goals and Milestones Done Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item Done Submit 'HTTP Authentication: MAC Authentication' as a working group item Done Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard Done Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard May 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard May 2012 Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard May 2012 Submit 'An IETF URN Sub-Namespace
Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
On 04/20/2012 03:40 PM, Michael Thomas wrote: Why not MUST ASN.1 while you're at it? JSON has won in case you'all haven't noticed it. Well, I also remember when XML won over ASN.1, or was that some RPC thing? Seems like a new format wins about every five years or so, once the last winner gets enough crap added. (JSON pointer seems like the start of a nice slippery slope to me.) I've no opinion as to what should be MTI here however, just a side comment. S Mike ___ apps-discuss mailing list apps-disc...@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] web sso study...
Hi all, A recent news article [1] was brought to my attention this week that's about a paper [2] which I've just read. While it mostly deals with implementation and integration flaws, I'm wondering if there's anything in there that could benefit any of the oauth drafts. Anyone had a look at that already? Be interesting if any similar analysis has been done on any oauth 1.0 or 2.0 sites or implementations. Ta, S. [1] http://www.itbusiness.ca/it/client/en/CDN/News.asp?id=66741 [2] https://research.microsoft.com/pubs/160659/websso-final.pdf ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
Hi All, So Hannes and Derek and I have been discussing this with the Apps ADs and Apps-area WG chairs. I've also read the docs now, and after all that we've decided that this topic (what to do with swd and webfinger) is best handled in the apps area and not in the oauth WG. The logic for that is that 1) the two proposals are doing the same thing and we don't want two different standards for that, b) this is not an oauth-specific thing nor is it a general security thing, and c) there is clearly already interest in the topic in the apps area so its reasonable for the oauth wg to use that when its ready. The appsawg chairs and apps ADs are ok with the work being done there. So:- - I've asked the oauth chairs to take doing work on swd out of the proposed new charter - It may be that you want to add something saying that oauth will use the results of work in the applications area on a web discovery protocol as a basis for doing the dynamic client registration work here - Discussion of webfinger and swd should move over to the apps-discuss list - Note: this is not picking one or the other approach, the plan is that the apps area will do any selection needed and figure out the best starting point for a standards-track RFC on web discovery and we'll use their fine work for doing more with oauth. Regards, Stephen. On 04/12/2012 12:00 PM, Hannes Tschofenig wrote: Hi all, those who had attended the last IETF meeting may have noticed the ongoing activity in the 'Applications Area Working Group' regarding Web Finger. We had our discussion regarding Simple Web Discovery (SWD) as part of the re-chartering process. Here are the two specifications: http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 Now, the questions that seems to be hanging around are 1) Aren't these two mechanisms solving pretty much the same problem? 2) Do we need to have two standards for the same functionality? 3) Do you guys have a position or comments regarding either one of them? Ciao Hannes PS: Please also let me know if your view is: I don't really know what all this is about and the documents actually don't provide enough requirements to make a reasonable judgement about the solution space. ___ 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
Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
On 04/12/2012 12:00 PM, Hannes Tschofenig wrote: Hi all, those who had attended the last IETF meeting may have noticed the ongoing activity in the 'Applications Area Working Group' regarding Web Finger. We had our discussion regarding Simple Web Discovery (SWD) as part of the re-chartering process. Here are the two specifications: http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 Now, the questions that seems to be hanging around are 1) Aren't these two mechanisms solving pretty much the same problem? 2) Do we need to have two standards for the same functionality? 3) Do you guys have a position or comments regarding either one of them? Ciao Hannes PS: Please also let me know if your view is: I don't really know what all this is about and the documents actually don't provide enough requirements to make a reasonable judgement about the solution space. So just as a data-point. We (the IETF, but including me personally;-) mucked up badly on this some years ago in the PKI space - we standardised both CMP (rfc 2510) and CMC (rfc 2797) as two ways to do the same thing, after a protracted battle between factions supporting one or the other. We even made sure they had as much common syntax as possible. (CRMF, rfc 2511) Result: neither fully adopted, lots of people still do proprietary stuff, neither can be killed off (despite attempts), both need to be maintained (CMP is now RFC 4210, CMC, 5272, CRMF, 4211), and IMO partly as a result of us screwing up for what seemed like good reasons at the time, PKI administration stuff has never gotten beyond horrible-to-do. All-in-all, a really bad outcome which is still a PITA a dozen years later. As OAuth AD I will need *serious* convincing that there is a need to provide two ways to do the same thing. I doubt it'll be possible to convince me, in fact, so if you wanna try, you'll need to start by saying that they are not in fact two ways to do the same thing:-) S. PS: This discussion needs to also involve the Apps area, so I've cc'd that list. ___ 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: Gen-ART Telechat review of draft-ietf-oauth-v2-25
FYI in case some aren't on i...@ietf.org Having responses to these before Thursday would be good. Its often the case that some AD will turn some of these points into a DISCUSS so good to know what can be cleared up easily and what might need further discussion before the telechat. S Original Message Subject: Gen-ART Telechat review of draft-ietf-oauth-v2-25 Date: Tue, 10 Apr 2012 09:11:19 -0400 From: Richard L. Barnes rbar...@bbn.com To: General Area Review Team gen-...@ietf.org, draft-ietf-oauth-v2@tools.ietf.org, IETF-Discussion list i...@ietf.org I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Document: draft-ietf-oauth-v2.txt Reviewer: Richard Barnes Review Date: 10 Apr 2012 IETF LC End Date: IESG Telechat Date: 12 Apr 2012 Summary: Almost ready, but with some gaps that need to be addressed MAJOR: General: At several points, the document seems to deal in plain-text usernames and passwords, ranging from the requirement for HTTP Basic authentication (2.3.1) to the explicit username and password fields one of the grant types (4.3.2, 10.7). In these cases, it seems like it would encourage better security practices to use some sort of digest or other secure scheme for proving ownership of passwords. Otherwise, there's a risk that proxies, caches, etc. will have access to users' plaintext credentials. General: The document requires the Authorization Server to distinguish between confidential and public clients at several points. It's not clear, however, how the server is supposed to tell which is which. Perhaps Section 2.1 could elaborate a little more on this? 4: Throughout the document, the assumption is that the client is moved from one URI to another via HTTP redirects (302 responses). Could the protocol also accommodate other techniques of moving clients around, e.g., in JavaScript (setting window.location). It seems like this could make deployment much easier in some cases. 10.3: This section seems to ignore the risk of client impersonation at the resource server. Just as with client credentials in Section 10.2, if an access token is compromised, then it could be presented by another party in order to access the protected resource. So the Resource Server needs to authenticate the client and validate that the token goes with the client, in addition to just checking the validity of the token. 10: Throughout this section, there are mentions of which parameters require secure transmission/storage and which do not. It would be helpful to summarize these requirements, say in a table at the end of the section. MINOR: 2.3.1: When you say request body in this section, do you actually mean query? I don't see a prohibition on GET here, in which case the parameters would be in the URI query section. 3.1.2.2: It seems like an explicit requirement would be helpful here, e.g.: The Authorization Server MUST verify that either no redirect_uri is provided (in which case it uses the registered URI), or else that the provided redirect_uri matches the registered redirection URI for the authenticated client_id (where the match can be based on a full or partial registered URI). 4.1.3: Why does this request use redirect_uri and not client_id to identify the client? (Or both?) It seems like involving the client_id would better support the goal of client authentication, in order to mitigate the risk of client impersonation. 4.3.2: Shouldn't there be a client authentication here? (In particular, a client_id.) Otherwise, it seems like this is essentially the same as the flow in 4.4. 7. It seems like it would be helpful to have a way to pass access tokens in the request URI / query in some deployment cases (e.g., a JavaScript based client). Is there any particular reason this was excluded? EDITORIAL: 3. Would be helpful to note here that these endpoints are in addition to the resource endpoint (the one started out to protect), which is handled in Section 7. 3.2: It's not clear why only POST is allowed here. A couple of words of explanation would help. 5.1: Why bother with a case-insensitive token_type here? It doesn't look like anything else in the whole document has this property. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-24.txt
Thanks Eran, A question... Is this text in 3.1.2.5 correct? If third-party scripts are included, the client MUST NOT ensure that its own scripts (used to extract and remove the credentials from the URI) will execute first. MUST NOT ensure is a really odd construct. Maybe s/NOT//? S On 03/08/2012 05:46 AM, Eran Hammer wrote: This draft is ready to go to IESG Review. EH -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org Sent: Wednesday, March 07, 2012 9:42 PM To: i-d-annou...@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-24.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : The OAuth 2.0 Authorization Protocol Author(s) : Eran Hammer David Recordon Dick Hardt Filename: draft-ietf-oauth-v2-24.txt Pages : 66 Date: 2012-03-07 The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-24.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-24.txt ___ 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] progressing base and bearer
First, thanks all, but especially editors and chairs, for your efforts on these. I'll be putting them on an IESG telechat agenda very shortly. That'll be for after the Paris meeting though, but only because we have a monster 700 pages of I-Ds to go through for next week's telechat due to outgoing ADs clearing the decks before they escape. So these'll likely be considered by the IESG for the April 12th telechat. Cheers, S. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] ID Tracker State Update Notice: draft-ietf-oauth-v2-bearer-17.txt
Hi Mike, On 03/08/2012 03:31 PM, Mike Jones wrote: Hi Stephen, I wanted to verify that, despite this state change, that it's still OK for me to make the editorial change suggested by the WG to the Bearer spec to change the b64token example. Sure. Changes the WG want that don't conflict with anything hammered out in WGLC or IETF LC between now and about a week before the IESG telechat (i.e. ~April 5th) are fine IMO but best to be guided by the WG chairs - in this case I don't recall the change you mean but I bet the WG chairs do. In other words, just check with the chairs before posting new revs is a good plan from now on. Cheers, S. Thanks, -- Mike -Original Message- From: IETF Secretariat [mailto:ietf-secretariat-re...@ietf.org] Sent: Thursday, March 08, 2012 3:07 AM To: oauth-cha...@tools.ietf.org; draft-ietf-oauth-v2-bea...@tools.ietf.org Subject: ID Tracker State Update Notice:draft-ietf-oauth-v2-bearer-17.txt State changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] REVISED Last Call: draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
Folks, The OAuth bearer and base last calls had to be re-done since I forgot to include some downref information. Other than adding a day to IETF LC, there should be no other difference. Sorry about that. S On 01/24/2012 03:00 PM, The IESG wrote: The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' draft-ietf-oauth-v2-bearer-15.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2012-02-07. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a bearer) can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. * There is a normative reference to RFC 2246 (TLS 1.0), which has been obsoleted by RFC 5246 (TLS 1.2). 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth specs in IETF last call
On 01/23/2012 05:11 PM, Mike Jones wrote: FYI, the OAuth Core and Bearer specifications have reached IETF last call status - the last step before becoming RFCs. See the following notes from the Internet Engineering Steering Group (IESG). Not quite the last step. There may be directorate reviews, then IESG evaluation follows, then the RFC editor queue. But we're getting there:-) S -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of The IESG Sent: Monday, January 23, 2012 7:44 AM To: IETF-Announce Cc: oauth@ietf.org Subject: [OAUTH-WG] Last Call:draft-ietf-oauth-v2-23.txt (The OAuth 2.0 Authorization Protocol) to Proposed Standard 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 The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2012-02-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ No IPR declarations have been submitted directly on this I-D. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of The IESG Sent: Monday, January 23, 2012 7:47 AM To: IETF-Announce Cc: oauth@ietf.org Subject: [OAUTH-WG] Last Call:draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' draft-ietf-oauth-v2-bearer-15.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2012-02-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a bearer) can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ No IPR declarations have been submitted directly on this I-D. ___ 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
Re: [OAUTH-WG] AD Review of -22 (part III)
As before, Thanks S On 21 Jan 2012, at 02:53, Eran Hammer e...@hueniverse.com wrote: -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Stephen Farrell Sent: Thursday, October 13, 2011 10:13 AM Original list of nits: -- - Intro: Maybe add some ascii-art showing the roles of the user, browser, client etc. The term client as used here is still commonly confusing and especially worth going the extra mile to clarify, before it is first used. What I think needs to be said early is that what is here called a client is normally (running on) a web server. Happy to take suggestions, but can't come up with a useful diagram myself. Added to the client definition: The term client does not imply any particular implementation characteristics (e.g. whether the application executes on a server, a desktop, or other devices). - p4: Maybe s/a string/an octet string/ in the token descriptions, unless the access token encoding is constrained to what'd be understood as a string. Just a string. - p8: Seems odd to speak of issuing an implicit grant - wouldn't that make something explicit? Maybe say With an implicit grant... instead in the 2nd para of 1.3.2? Changed to 'When issuing an access token during the implicit grant flow'. - p8: I don't get what its device operating system means. Do you mean the client is an already-trusted part of the resource owner's device OS? Changed to 'the client is part of the device operating system'. - p9 - Issuing a refresh token is optional - might be better to say that it's the authorization server's choice and there's no way for the client to signal a request for one. Changed to 'Issuing a refresh token is optional at the discretion of the authorization server.' - p10 - In figure 2, why is the Refresh token shown as optional in step (H) but not in step (B)? I think it'd be clearer for the figure to reflect the protocol options and say that the refresh token is optional in (B) as well. Because this is the refresh token flow. If it is optional, there is no flow... - p12 - the confidential/public terminology isn't great, did the WG consider authenticating vs. non-authenticating? Trying again to find better terms would maybe be worthwhile. Didn't try this particular alternative, but it doesn't flow off my tongue. Also, it may be worth explicitly saying that it doesn't matter how hard to guess a secret the client has nor how good a MAC algorithm you use with that secret - if anyone can get the secret then the client is still public. It nearly says that, but not quite and given that many developers just don't apparently still think that a hardcoded secret embedded into a binary is good enough, I'd argue its worth adding a bit more here. This seems to be cross the line as to what the server defines as confidential, but I'm happy to take text proposals. - p12/13 in the application profile descriptions - is resource owner's device correct? That seems to rule out kiosks, which may be correct, but which isn't obvious. Maybe you mean device being used by the resource owner with no implication as to ownership of the device? Changed to 'the device used by the resource owner' throughout. - p13 - client application: typos: s/such access tokens/such as access tokens/ s/which...interact with/with which the application may interact/ Ok. - p13, establishing trust with the client or its developer is badly phrased, I think you mean the AS SHOULD NOT just accept the client type unless it has some external reason to do so. Trusting the developer might be one such. Being paid is another, and maybe more likely;-) Changed to: The authorization server SHOULD NOT make assumptions about the client type, nor accept the type information provided by the client developer without first establishing trust. - p13, 2.3 has 2119 language both about the things established at registration time and things done in the protocol defined here - would it be better to identify those separately in different sections or maybe move the registration time stuff into 2.2 with a possible renaming of 2.2. Tweaked a bit, but overall it reads fine to me. - 3.1.2.1 has a SHOULD for TLS which I think generated a lot of mail on the list. I think saying why this is not a MUST would be useful, since it's the kind of thing that might get revised later on if the situation changes. This specification does not mandate the use of TLS because at the time of this writing, requiring clients to deploy TLS is a significant hurdle for most client developers. - Figure 3, (p21) has multiple lines labeled A,B C - saying why might reduce some confusion. Or maybe, say that the labels reflect rough event timing or something. It'd
Re: [OAUTH-WG] Mandatory to Implement Interoperability
Hannes, I don't see any proposed text here, I see re-chartering suggestions. The latter is not going to happen if the current main documents are wedged. Please focus on the former now. You know that I disagree with you and a number of WG participants about this, so no need for me to repeat myself, other than to say that I've always said pick an MTI, *or* say (convincingly) what that's not needed and you've not addressed the latter. Barry's text did do that. The fact that a) the room in Taipei seemed to agree with MTI, b) the list seemed to agree with Barry's suggested text, and c) this new suggested programme also gets a bunch of +1's all seems to me to imply that people are not sufficiently focused on getting this finished but would still prefer to get what they think of as perfection. S. PS: I would also quibble that the lessons from keyprov are highly relevant here, but let's not:-) On 12/08/2011 09:15 PM, Alexey Melnikov wrote: On 08/12/2011 14:18, Hannes Tschofenig wrote: Hi all, Hi Hannes, Some random thoughts about your message below: I read through this rather long mail thread again and see whether we are reaching any conclusion on this discussion. In turns out that there are actually two types of discussions that relate to each other, namely the TLS version support and the token type. Let me go back in time a little bit when I was still chairing another working group (years ago), namely the KEYPROV working group. There we ran into a similar issue, which looked fairly simple at the beginning. We worked on Portable Symmetric Key Container (PSKC), later published as RFC 6030. We were at the stage where we thought we had to decide on a mandatory-to-implement cryptographic algorithm and, similar to the OAuth case, PSKC is one building block in a larger protocol suite. As you can imagine, everyone had their own deployment environment in mind and did not like the suggestion others made about what as mandatory to implement. Russ (now IETF chair and at that time security area director) told the group not to worry - we don't need to pick an algorithm. He suggested to just provide a recommendation of what is best in a specific deployment environment (at the time of writing). In fact, he proposed to publish a separate document instead to discussing it in that document. I was surprised because I was couldn't see how one would accomplish interoperability. Russ told me that this is in practice not a problem because implementations often implement a range of cryptographic algorithms anyway. Then, as part of the algorithm negotiation procedure (or some discovery) they will figure out what both end points support. He further argued that algorithm preferences will change (as algorithms get old) and we don't want to update our specifications all the time. (This was a bit motivated by the MD5 clean-up that happened at that time.) [Please forgive me if I do not recall the exact words he said many years ago.] I believe we are having a similar discussion here as well, both with the token type but also with the TLS version. We look at individual specifications because we are used to add security consideration sections to each and every document. Unfortunately, the most useful statements about security (for these multi-party protocols where the functionality is spread over multiple documents) can really only be made at a higher level. Our approach for describing security threats and for recommending countermeasures isn't suitable to all the documents we produce. Let me list a few desirable results of our standardization work: 1) Everyone wants interoperability. We can do interop testing of building blocks to see whether a client and a server are able to interact. For example, we could write a few test cases to see how two independent bearer token specifications work with each other. That approach works for some of our building blocks. I do, however, believe that we are more interested of an interoperable system consisting of several components rather than having interop between random components. Even if we do not like it, OAuth is an application level protocol that requires a number of things to be in place to make sense. 2) We want libraries to be available that allow implementers to quickly OAuth-enable their Web applications, i.e., by quickly I mean that an application develop shouldn't have to write everything from scratch. Most of the development time will be spent on aspects that are not subject to standardization in the working group (such as the user interface and the actual application semantic -- the data sharing that happens once the authorization step is completed). These libraries are likely to support various extensions and getting two different implementations to interwork will IMHO in practice not be a problem. However, for a real deployment it seems that the current direction where people are going is more in the line of trust frameworks where much more than just technical
Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base
All but the last bit seems ok to me FWIW. I don't know what an additional transport-layer mechanism might be. I'd say just leave that bit out. TLS is already a MUST implement. S On 12/09/2011 06:30 PM, Mike Jones wrote: It looks to me like there is consensus for Barry's text (below). Agreed? -- Mike 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. -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Peter Saint-Andre Sent: Thursday, December 01, 2011 12:59 PM To: Stephen Farrell Cc: Barry Leiba; oauth WG Subject: Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base On 12/1/11 1:57 PM, Stephen Farrell wrote: On 12/01/2011 08:10 PM, Peter Saint-Andre wrote: On 12/1/11 1:09 PM, Rob Richards wrote: On 11/28/11 10:39 PM, Barry Leiba wrote: 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 Text is neutral enough for me as it's not mandating anything that isn't readily available. Only comment is whether or not there is a need to even talk about the specific versions or if just the following is enough: 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. Servers MAY also implement additional transport-layer mechanisms that meet their security requirements. That seems fine to me. FWIW, I think I'd prefer Barry's as Rob's would be more likely to generate discusses and we do know that there are some security advantages to TLS 1.2 vs. 1.0. (BTW, has anyone considered how or if the BEAST attack might affect oauth? Be good to know if someone's done that analysis.) However, as AD, I could live with either, since lots of other specs just say TLS. (But you need to point to the latest RFC as normative or that will I bet generate discusses.) Agreed. Peter -- Peter Saint-Andre https://stpeter.im/ ___ 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
Re: [OAUTH-WG] Mandatory-to-implement token type
FWIW, if Barry's suggested text was amended to say MUST do bearer, MAY do mac I'd still be ok with that. Much as I'd like if the mac scheme were more popular, my comment on -22 was interop and not really security related. S On 12/04/2011 01:15 PM, Paul Madsen wrote: Commercial OAuth authorization servers are neither 'toolkits' nor 'purpose built code' - not used to build OAuth clients/servers but yet required to support more variety in deployments than a single purpose built server. But, that variety is driven by customer demand, and none of ours (yet?) have demanded MAC. If and when that demand comes, we will add support. To stipulate MAC as MTI would in no way reflect what the market wants. And 'interop' nobody wants is not meaningful interop. paul On 12/3/11 4:37 PM, Barry Leiba wrote: 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 ___ 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
Re: [OAUTH-WG] Mandatory-to-implement token type
Whatever. If the entire WG want to get excited by the difference between MAY do mac and not mentioning it then fine. Personally, I'd be more interested in getting done rather than nailing that final nail into any coffin;-) S On 12/04/2011 02:21 PM, Mike Jones wrote: The core spec should be completely silent on MAC, as it is not ready for prime time. -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Stephen Farrell Sent: Sunday, December 04, 2011 6:20 AM To: Paul Madsen Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Mandatory-to-implement token type FWIW, if Barry's suggested text was amended to say MUST do bearer, MAY do mac I'd still be ok with that. Much as I'd like if the mac scheme were more popular, my comment on -22 was interop and not really security related. S On 12/04/2011 01:15 PM, Paul Madsen wrote: Commercial OAuth authorization servers are neither 'toolkits' nor 'purpose built code' - not used to build OAuth clients/servers but yet required to support more variety in deployments than a single purpose built server. But, that variety is driven by customer demand, and none of ours (yet?) have demanded MAC. If and when that demand comes, we will add support. To stipulate MAC as MTI would in no way reflect what the market wants. And 'interop' nobody wants is not meaningful interop. paul On 12/3/11 4:37 PM, Barry Leiba wrote: 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 ___ 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
Re: [OAUTH-WG] Mandatory-to-implement token type
Hiya, On 12/04/2011 06:51 PM, Eran Hammer-Lahav wrote: This has been going on for far too long. There is a well-established gap between the two tokens and those who support them and we are NEVER going to reach consensus. Instead we have a war of attrition were each side is just keeping at it hoping the other side will give up. The only compromise we were able to reach in 2 years is to keep the v2 specification token agnostic. If we are now going to violate that for the perceived notion of interoperability, we should at least do it with due process. Stephen - In previous discussion, my understanding was that you were opposed to publishing OAuth 2.0 without MAC because that would make 2.0 a less secure option than 1.0. While, as you stated, this thread is not about security but about interoperability, the two are at odds here and you can only have one. If the specification picked a winner by making only one required, and if that one is Bearer, I see no point whatsoever in spending any more of my time on MAC. It would be DOA. I do dislike the idea of not having a better scheme than bearer. I don't have so much of an issue about its 2119 status (MUST vs. MAY) so long as its well defined (having said that I'd presonally prefer MUST). I guess you and I disagree about the significance of that status issue. But as you say though that's a different issue from the one currently under discussion so I'd rather keep things separate and move along. (That is, if someone wants to chat about desirable security levels please change at least the subject line.) The WG is clearly opposed to making MAC required, but that is not the only question to ask. The question for the group is also, do you even want MAC? Are you planning on using it? And will you use it alongside Bearer or exclusively? If there is sufficient WG support for MAC, making Bearer required alone violates that spirit because it will make MAC another specification no one cares about and we don't need more of those. If there is no sufficient support, let's just drop it as a WG item and let it resurface later if at all. As for the market has decided argument - I only want to warn those who use it that it is a double-edge-sword. The same people who now use that argument are also the members of this group responsible for some of the new astronaut architecture features proposed in the rechartering discussion. If you intend to make this your winning argument, the WG must then apply the same rational to your other proposals. Well, I wouldn't be quite so black-and-white about it, but its a fair comment to say that arguing against mac but for use of oauth for higher security environments could raise some questions. I've not tracked if someone's actually making just that argument however, so I guess this won't come up until a) we've got the base spec out and b) the WG have proposed some new charter. If a proposed new charter assumes something the work-to-date has not delivered then something will have to give, so I'd encourage the WG to consider that as they discuss re-chartering. I'm confident however that the WG chairs would spot that and help try to direct the WG towards something self-consistent. Again though, that's also not the current issue under discussion, and in that case, I guess there is (or was, seems quiet now) a re-chartering thread that seems appropriate for that topic. Cheers, S. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Stephen Farrell Sent: Sunday, December 04, 2011 6:44 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Mandatory-to-implement token type Whatever. If the entire WG want to get excited by the difference between MAY do mac and not mentioning it then fine. Personally, I'd be more interested in getting done rather than nailing that final nail into any coffin;-) S On 12/04/2011 02:21 PM, Mike Jones wrote: The core spec should be completely silent on MAC, as it is not ready for prime time. -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Stephen Farrell Sent: Sunday, December 04, 2011 6:20 AM To: Paul Madsen Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Mandatory-to-implement token type FWIW, if Barry's suggested text was amended to say MUST do bearer, MAY do mac I'd still be ok with that. Much as I'd like if the mac scheme were more popular, my comment on -22 was interop and not really security related. S On 12/04/2011 01:15 PM, Paul Madsen wrote: Commercial OAuth authorization servers are neither 'toolkits' nor 'purpose built code' - not used to build OAuth clients/servers but yet required to support more variety in deployments than a single purpose built server. But, that variety is driven by customer demand, and none of ours (yet?) have demanded MAC. If and when that demand comes, we will add support. To stipulate MAC as MTI would in no way reflect what
Re: [OAUTH-WG] Mandatory-to-implement token type
Hi Barry, 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.j That'd work just fine for me. Barry, as participant Stephen, as breakfast eater:-) ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base
On 12/01/2011 08:10 PM, Peter Saint-Andre wrote: On 12/1/11 1:09 PM, Rob Richards wrote: On 11/28/11 10:39 PM, Barry Leiba wrote: 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 Text is neutral enough for me as it's not mandating anything that isn't readily available. Only comment is whether or not there is a need to even talk about the specific versions or if just the following is enough: 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. Servers MAY also implement additional transport-layer mechanisms that meet their security requirements. That seems fine to me. FWIW, I think I'd prefer Barry's as Rob's would be more likely to generate discusses and we do know that there are some security advantages to TLS 1.2 vs. 1.0. (BTW, has anyone considered how or if the BEAST attack might affect oauth? Be good to know if someone's done that analysis.) However, as AD, I could live with either, since lots of other specs just say TLS. (But you need to point to the latest RFC as normative or that will I bet generate discusses.) Cheers, S. Peter ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Mandatory-to-implement token type
Barry, all, First, apologies for being so slow responding, various travels got in the way. I hope we can quickly resolve this now. Bit of process first: at the meeting we discussed this and at the end of that discussion, there were quite a few more folks for the pick one position. People who favour that outcome and really care about that need to speak up on the list, since the list consensus trumps the sense of the room in the chairs' evaluation of the WG consensus. Second, at the meeting I said that I'd like to see either MAC or bearer picked as MTI, and if not, that I want the draft to say why its ok to have no MTI token type. So the WG either need to pick one, or else explicitly and convincingly justify not picking one. That's the firm AD position to which Barry referred. (I didn't properly call out the if not part of that in my AD review, sorry.) My own argument for picking one is simple: if every relevant piece of code has to know how to handle one then it becomes easier to get interop. If everyone decides for themselves then interop is less likely since there are currently two choices and may be more in future. I do realise that the background here and current practice is that code tends to be written that is specific to a resource server (or however that's best phrased) but that's maybe where the IETF differs from the community that produced OAuth - here we want two independent implementers who've never talked to produce code that interops even so. I also realise that that's not the full story for getting interop with OAuth and that more is needed. However, this aspect is otherwise fully specified and so I don't buy the argument that this isn't worth doing just because we don't have the full registration story etc. figured out. If we don't sort this out now, then later specs will have to update this one in this respect. possibly making existing code non-compliant in some sense, so just going ahead and doing it right now is better. So, pick one (my strong personal preference) or establish and document why you're not picking one seem to me to be the choices available. Regards, Stephen. On 11/17/2011 08:28 AM, Barry Leiba wrote: 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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Mandatory-to-implement token type
On 12/01/2011 11:37 PM, William Mills wrote: Re: So, pick one (my strong personal preference) or establish and document why you're not picking one seem to me to be the choices available. We don't have discovery done (enough) yet to lean on it in the core spec, but if we did I'd be in favor of something that says that you must implement either an MTI token OR a discovery mechanism that advertises at least one token. Would that be workable? Might be, but I think the if we did says timing is against that argument. We could bang on the discovery stuff in pretty short order I think if we needed to. Really? Doesn't the WG first need to recharter? We're talking about how to get the base spec to be an RFC right now, which is a shorter term thing IMO. S. -bill From: Stephen Farrellstephen.farr...@cs.tcd.ie To: Barry Leibabarryle...@computer.org Cc: oauth WGoauth@ietf.org Sent: Thursday, December 1, 2011 1:25 PM Subject: Re: [OAUTH-WG] Mandatory-to-implement token type Barry, all, First, apologies for being so slow responding, various travels got in the way. I hope we can quickly resolve this now. Bit of process first: at the meeting we discussed this and at the end of that discussion, there were quite a few more folks for the pick one position. People who favour that outcome and really care about that need to speak up on the list, since the list consensus trumps the sense of the room in the chairs' evaluation of the WG consensus. Second, at the meeting I said that I'd like to see either MAC or bearer picked as MTI, and if not, that I want the draft to say why its ok to have no MTI token type. So the WG either need to pick one, or else explicitly and convincingly justify not picking one. That's the firm AD position to which Barry referred. (I didn't properly call out the if not part of that in my AD review, sorry.) My own argument for picking one is simple: if every relevant piece of code has to know how to handle one then it becomes easier to get interop. If everyone decides for themselves then interop is less likely since there are currently two choices and may be more in future. I do realise that the background here and current practice is that code tends to be written that is specific to a resource server (or however that's best phrased) but that's maybe where the IETF differs from the community that produced OAuth - here we want two independent implementers who've never talked to produce code that interops even so. I also realise that that's not the full story for getting interop with OAuth and that more is needed. However, this aspect is otherwise fully specified and so I don't buy the argument that this isn't worth doing just because we don't have the full registration story etc. figured out. If we don't sort this out now, then later specs will have to update this one in this respect. possibly making existing code non-compliant in some sense, so just going ahead and doing it right now is better. So, pick one (my strong personal preference) or establish and document why you're not picking one seem to me to be the choices available. Regards, Stephen. On 11/17/2011 08:28 AM, Barry Leiba wrote: 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 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
Re: [OAUTH-WG] Mandatory-to-implement token type
On 12/02/2011 12:23 AM, Phil Hunt wrote: Because different token types have distinct advantages in different scenarios, choosing a single MTI would be difficult. I just don't get that. Why is it somehow difficult to pick one but at the same time easy to implement any? E.g. MAC tokens work well for non-TLS protected resources. Bearer tokens in contrast are easier to use, but require TLS protected service to avoid theft-of-credential. So picking is a nuisance sure. But it helps interop. Even at this level, site security policies will simply override whatever is stated in the specification and choose one type only. Yes, but those policies will be affected by what's available in the running code. I'd like if what's available was known when the coder says we implement RFC foo Having multiple MTIs, suggests choice and that causes other problems. What happens when a client wants to use a bearer token over an unprotected connection? How does the client discover what can be used and when? Having no MTI causes identical problems. The approach we have now where the Token specification defines interop requirements and a profile for use with OAuth2 seems to be a good way to go. We disagree about that I guess. To me it seems a peculiar way to go unless one assumes that coders write code that's specific to a specific service provider. S. Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-12-01, at 1:25 PM, Stephen Farrell wrote: Barry, all, First, apologies for being so slow responding, various travels got in the way. I hope we can quickly resolve this now. Bit of process first: at the meeting we discussed this and at the end of that discussion, there were quite a few more folks for the pick one position. People who favour that outcome and really care about that need to speak up on the list, since the list consensus trumps the sense of the room in the chairs' evaluation of the WG consensus. Second, at the meeting I said that I'd like to see either MAC or bearer picked as MTI, and if not, that I want the draft to say why its ok to have no MTI token type. So the WG either need to pick one, or else explicitly and convincingly justify not picking one. That's the firm AD position to which Barry referred. (I didn't properly call out the if not part of that in my AD review, sorry.) My own argument for picking one is simple: if every relevant piece of code has to know how to handle one then it becomes easier to get interop. If everyone decides for themselves then interop is less likely since there are currently two choices and may be more in future. I do realise that the background here and current practice is that code tends to be written that is specific to a resource server (or however that's best phrased) but that's maybe where the IETF differs from the community that produced OAuth - here we want two independent implementers who've never talked to produce code that interops even so. I also realise that that's not the full story for getting interop with OAuth and that more is needed. However, this aspect is otherwise fully specified and so I don't buy the argument that this isn't worth doing just because we don't have the full registration story etc. figured out. If we don't sort this out now, then later specs will have to update this one in this respect. possibly making existing code non-compliant in some sense, so just going ahead and doing it right now is better. So, pick one (my strong personal preference) or establish and document why you're not picking one seem to me to be the choices available. Regards, Stephen. On 11/17/2011 08:28 AM, Barry Leiba wrote: 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
Re: [OAUTH-WG] Mandatory-to-implement token type
Hiya, On 12/02/2011 01:38 AM, Michael D Adams wrote: I echo Justin Richer's comments. On Thu, Nov 17, 2011 at 12:28 AM, Barry Leibabarryle...@computer.org wrote: 1. Should we specify some token type as mandatory to implement? Why or why not (*briefly*)? No. There's no mechanism in the spec for clients to request a particular token type, so there's no opportunity for the authorization server to decide what token type to send. The only thing the authorization server can do is pick its own preference. If there's an MTI token type, and with the absence of a client preference, the authorization server will have to pick the MTI token type. 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. So I don't get your argument. (When thinking of interop.) S. Mike PS: I sent this 2011/11/17 but apparently hit reply instead of reply all. ___ 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
Re: [OAUTH-WG] Mandatory-to-implement token type
On 12/02/2011 01:50 AM, William Mills wrote: If we MTI a weaker token type (arguably Bearer falls here) that means the spec will be inappropriate in higher security requirement situations, those folks walk away. Disagree. People who need more can specify more. The base spec not having an MTI doesn't help them at all since absent any MTI it'd clearly not be appropriate for higher security environments to use your term. If we MTI something like SAML it makes the folks that want a light weight Bearer token solution walk away. I would agree that SAML might be too heavy. If the WG do pick an MTI then it does need to be relatively simple. S. From: Stephen Farrellstephen.farr...@cs.tcd.ie To: Phil Huntphil.h...@oracle.com Cc: Barry Leibabarryle...@computer.org; oauth WGoauth@ietf.org Sent: Thursday, December 1, 2011 5:23 PM Subject: Re: [OAUTH-WG] Mandatory-to-implement token type On 12/02/2011 12:23 AM, Phil Hunt wrote: Because different token types have distinct advantages in different scenarios, choosing a single MTI would be difficult. I just don't get that. Why is it somehow difficult to pick one but at the same time easy to implement any? snip / From: Stephen Farrellstephen.farr...@cs.tcd.ie To: Phil Huntphil.h...@oracle.com Cc: Barry Leibabarryle...@computer.org; oauth WGoauth@ietf.org Sent: Thursday, December 1, 2011 5:23 PM Subject: Re: [OAUTH-WG] Mandatory-to-implement token type On 12/02/2011 12:23 AM, Phil Hunt wrote: Because different token types have distinct advantages in different scenarios, choosing a single MTI would be difficult. I just don't get that. Why is it somehow difficult to pick one but at the same time easy to implement any? E.g. MAC tokens work well for non-TLS protected resources. Bearer tokens in contrast are easier to use, but require TLS protected service to avoid theft-of-credential. So picking is a nuisance sure. But it helps interop. Even at this level, site security policies will simply override whatever is stated in the specification and choose one type only. Yes, but those policies will be affected by what's available in the running code. I'd like if what's available was known when the coder says we implement RFCfoo Having multiple MTIs, suggests choice and that causes other problems. What happens when a client wants to use a bearer token over an unprotected connection? How does the client discover what can be used and when? Having no MTI causes identical problems. The approach we have now where the Token specification defines interop requirements and a profile for use with OAuth2 seems to be a good way to go. We disagree about that I guess. To me it seems a peculiar way to go unless one assumes that coders write code that's specific to a specific service provider. S. Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-12-01, at 1:25 PM, Stephen Farrell wrote: Barry, all, First, apologies for being so slow responding, various travels got in the way. I hope we can quickly resolve this now. Bit of process first: at the meeting we discussed this and at the end of that discussion, there were quite a few more folks for the pick one position. People who favour that outcome and really care about that need to speak up on the list, since the list consensus trumps the sense of the room in the chairs' evaluation of the WG consensus. Second, at the meeting I said that I'd like to see either MAC or bearer picked as MTI, and if not, that I want the draft to say why its ok to have no MTI token type. So the WG either need to pick one, or else explicitly and convincingly justify not picking one. That's the firm AD position to which Barry referred. (I didn't properly call out the if not part of that in my AD review, sorry.) My own argument for picking one is simple: if every relevant piece of code has to know how to handle one then it becomes easier to get interop. If everyone decides for themselves then interop is less likely since there are currently two choices and may be more in future. I do realise that the background here and current practice is that code tends to be written that is specific to a resource server (or however that's best phrased) but that's maybe where the IETF differs from the community that produced OAuth - here we want two independent implementers who've never talked to produce code that interops even so. I also realise that that's not the full story for getting interop with OAuth and that more is needed. However, this aspect is otherwise fully specified and so I don't buy the argument that this isn't worth doing just because we don't have the full registration story etc. figured out. If we don't sort this out now, then later specs will have to update this one in this respect. possibly making existing code non-compliant in some sense, so just going ahead and doing it right now is better. So, pick one (my
Re: [OAUTH-WG] Mandatory-to-implement token type
Hiya, On 12/02/2011 02:14 AM, Michael D Adams wrote: On Thu, Dec 1, 2011 at 5:44 PM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 12/02/2011 01:38 AM, Michael D Adams wrote: 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. So I don't get your argument. (When thinking of interop.) I think it's me that doesn't understand your argument. That can be mutual:-) Suppose an authorization server implements OAuth2 and has some requirement that the MTI token type doesn't provide (as William Mills suggested), so the server implements token type AWESOME in addition to token type MTI. Whenever a token is requested, the authorization server issues one of type AWESOME. Type MTI is never issued. Why bother implementing type MTI if it's never used? That, I think, assumes that the requesting party only ever works with the AWESOME token-type issuer. Seems a shame to me that whoever wrote that code can't work with any other MTI token-type issuer as well, at least. Additionally, the authorization server could not implement type MTI but claim it did. There's no way for a third party to verify the claim since the authorization server never issues a token of type MTI. Irrelevant. I could claim to be handsome. Would work equally well. If tokens of type MTI are never used by this server, how does the MTI token type help interop?Is your argument that this server would say No, we do not support OAuth2. We do, however, support OAuth2+AWESOME.? That semantic argument I understand, but I am ignorant as to how/if it fits into the RFC. No, my argument is that there are many servers and many clients on the Internet and having them all have a way to interop, if they choose to do so, is a good thing in itself. Writing an RFC so that its a random pick as to whether they do or don't interop is not IMO a good thing. S. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] wg summaries
Reminder: please send your wg summary messages to saag before the session at 1520! Nea and oauth: I know that's quite demanding Dane: you met Monday :-) Thanks, S. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] wg summaries
oops - meant just for the chairs, apologies. S On 11/17/2011 02:44 AM, Stephen Farrell wrote: Reminder: please send your wg summary messages to saag before the session at 1520! Nea and oauth: I know that's quite demanding Dane: you met Monday :-) Thanks, S. ___ 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
Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-14
On 11/05/2011 07:36 PM, Hannes Tschofenig wrote: Hi all, after a discussion with Stephen we decided that it would be useful to have draft-ietf-oauth-v2-bearer-14 submitted during the blackout period so that we have the most recent feedback incorporated already before the IETF meeting starts. Stephen will talk to the secretary to enable the submission and I will approve it. Done. Might take 'em a few days - they're busy with travel and meeting prep. S ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] AD review of draft-ietf-oauth-bearer-13
Hi, Good work - another one almost out the door! Thanks. However, I think this one needs a revised ID before we start IETF LC. Nothing hard to change I hope, but I think there are enough changes to make that its best done that way. I reckon items 3,5,7-11 and 13 below need fixing, but are I hope all easy. Not sure about item 4. All my other comments can be considered in conjunction with whatever other IETF LC comments we get, or now, whichever. If you want to argue that the WG already had strong consensus against a change I'm asking for, or that I'm just being dumb, (which happens all the time:-) then please do that and we can discuss it on the list and/or at the meeting. Regards, Stephen. questions/comments: 1) What does the 1st sentence of section 2 mean? What is the 2119 MAY for? Couldn't that sentence be deleted? If not, why not? 2) I think you should warn implementers in 2.3 that using the query string is fairly likely to result in the access token being logged, which is highly undesirable. (That is there later too, but I think deserves to be here.) What does the only feasible method mean? I think that needs to be defined, as was done in 2.2. 3) Where's it say what to do with a scope attribute presented by a server? 4) What is the realm attribute in section 3? What is a client expected to do with that? I guess it has to be different from how realm is used with e.g. Basic. (That might be my ignorance of HTTP details though;-) 5) Section 3 ABNF allows realm=foo;realm=bar;scope=baz;error=123 is that ok? Is processing clear for all cases? I don't think it is. 6) 3.1, invalid_token - the client MAY retry, SHOULD it do that in an infinite loop? Probably not;-) 7) Assuming token integrity protection is wrong. You need to make it a MUST. That is, you need to say that resource servers MUST only accept tokens with strong integrity or similar. 8) I think you need to say that TLS is MTI and MUST be used, (i.e. with 2119 language) and it'd be better to put that in the introduction as well as 4.2. 9) As-is 4.2 allows anonymous D-H TLS ciphersuites. I don't think you want that, but yet you only call for ciphersuites that offer confidentiality. I think that needs to be tightened up. 4.3 does tighten there, but I think 4.2's language also needs fixing. 10) The token validity doesn't have to be inside. I could e.g. change a token MAC verification key every hour and limit lifetime that way. 11) Two paragraphs in 4.2 contradict one another. 3rd last para say you MUST use TLS, 2nd last para says you MUST have confidentiality for instance...TLS. I'd ditch the second one I think, but something needs fixing. 12) Why reference 2818 instead of 6125? 13) I think you need to say something here about load balancers and other server side things that terminate TLS, before the resource server and behind which bearer tokens are unprotected. At least say that tokens MUST be protected there and provide guidance as to how to do that well. Lots of people do that badly I think. (At least at first;-) 14) Why are cookies first mentioned in 4.3? Seems like that should have been done earlier. nits: abstract: maybe s/granted resources/the associated resources/? abstract: s/the bearer token needs to/bearer tokens need to/? 1.2: s/abstraction layer/abstraction/ I don't see any layer there 2.1: I (and others) dislike the use of the reference as if it were part of the sentence, e.g. defined by [I-D.whatever],... Better would be defined as part of HTTP authentication [I-D.whatever] There are multiple occurrences of this. 2.1: s/follows/as follows/ 2.1, last para: I think the SHOULD in the last para of 2.1 and the corresponding rules in 2.2 2.3 would be better stated up front. end of p7, s/attribute MUST NOT/attributes MUST NOT/ 4.2, s/recommended/RECOMMENDED/ is better but they mean the same already! ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD review of -22
Hi Torsten, On 11/02/2011 07:45 PM, Torsten Lodderstedt wrote: Hi Stephen, I'm concerned about your proposal (7) to make support for MAC a MUST for clients and BEARER a MAY only. In my opinion, this does not reflect the group's consensus. That wasn't quite my comment, which is below: (7) Doesn't 7.1 need to say which token types are MTI so that we get interop? I think I'd like to see mac being a MUST and bearer being a MAY but regardless of my preference, I don't think you can be silent on this. And as a consequence one or both of the mac/bearer drafts need to end up as normative. Beside this, the security threat analysis justifies usage of BEARER for nearly all use cases as long as HTTPS (incl. server authentication) can be utilized. As I said, I personally prefer the mac scheme since it demonstrates use of a key. However, as I also said, the main concern with this point is interop. (I do note though that bearer has server-auth TLS as a MUST USE, so the implication of making bearer a MUST is that TLS is MTI for the base spec too and a MUST USE for anything involving the MTI token type.) In any case I can live with it so long as the set of things that are MTI is clear. Incidentally, I don't believe any amount of +1 messages to your mail answer my point above. As Eran's mail asks: what is it that you're suggesting be MTI for whom? S. regards, Torsten. Am 13.10.2011 19:13, schrieb Stephen Farrell: Hi all, Sorry for having been quite slow with this, but I had a bunch of travel recently. Anyway, my AD comments on -22 are attached. I think that the first list has the ones that need some change before we push this out for IETF LC, there might or might not be something to change as a result of the 2nd list of questions and the rest are really nits can be handled either now or later. Thanks for all your work on this so far - its nearly there IMO and we should be able to get the IETF LC started once these few things are dealt with. Cheers, S. ___ 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
Re: [OAUTH-WG] AD review of -22
Agnostic sounds like a fine word. I'd need to have it demonstrated to me that it doesn't mean non-interoperable in this case. S. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD review of -22
So perhaps this is the interesting point of difference. On 11/02/2011 08:37 PM, John Bradley wrote: It is up to the server to decide what formats it will support. With IETF protocols, its IETF consensus that decides this in almost all cases that affect interop and it is therefore not up to the specific server deployment admin what the server code will support. I think this case affects interop. and should be treated as for any other IETF protocol. Am I wrong? S ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Publication requested for draft-ietf-oauth-v2-bearer-12
Hi Hannes, Just looking at this now. The tracker [1] WG state shows revised ID needed - was that prior to the publication request or as a result of the comments on the list since you sent me this? If the former, I'll do my AD review now, if the latter then I guess I should wait and review a -13. Also - are you not able to enter the proto write up into the WG chair/shepherd tool thing? If so could you do that? (If you can't I can edit it in but would like to give the tool a spin if we can.) Ta, S. [1] https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ On 10/28/2011 07:36 AM, Hannes Tschofenig wrote: Hi Stephen, the OAuth working group requests publication of draft-ietf-oauth-v2-bearer-12 as Proposed Standard. Here is the write-up for the document. --- Document Shepherd Write-Up for draft-ietf-oauth-v2-bearer-12 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The document shepherd is Hannes Tschofenig. I have personally reviewed the document and I think it is ready for going forward. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document received a number of reviews from the working group but also from members outside the working group, including security reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? The document was reviewed by Julian Reschke for HTTP related content. Changes to the document have been made in response to his review. There is still disagreement between Julian and working group members regarding two issues concerning encoding. While the shepherd feels comfortable going forward with the specification to the IESG wider IETF review may provide additional feedback. One issue is related to the encoding of the scope attribute in context of HTTP authentication parameters: https://www.ietf.org/mail-archive/web/oauth/current/msg07733.html https://www.ietf.org/mail-archive/web/oauth/current/msg07734.html https://www.ietf.org/mail-archive/web/oauth/current/msg07739.html The other comment by Julian is related to the form encoding, as described here: https://www.ietf.org/mail-archive/web/oauth/current/msg07731.html (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I have no concerns regarding this document but would like to appreciate feedback from the wider IETF community on the issues raised under item 1.c. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There solid consensus behind this document from the working group. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) Nobody had shown extreme discontent. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? I have verified the document. The idnits tool gives a warning about the RFC 2119 boilerplate, and that warning is incorrect. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are
[OAUTH-WG] AD review of -22
Hi all, Sorry for having been quite slow with this, but I had a bunch of travel recently. Anyway, my AD comments on -22 are attached. I think that the first list has the ones that need some change before we push this out for IETF LC, there might or might not be something to change as a result of the 2nd list of questions and the rest are really nits can be handled either now or later. Thanks for all your work on this so far - its nearly there IMO and we should be able to get the IETF LC started once these few things are dealt with. Cheers, S. List 1 - Fairly sure these need changes: (1) In 2.3.1 MUST the AS support both HTTP basic and the client_id and client_secret in the request schemes? You say it MAY allow credentials in the request body, but that's different from what the AS coder has to implement. Saying an AS that issues passwords MUST support basic over TLS and MAY support including credentials in the body would seem right here. (2) In 2.3.1 (and more generally) what does MUST require the use of a transport-layer security mechanism really mean? I think you need to say explicitly what this means in terms of TLS and which version of TLS and which ciphersuites etc. Doing that once is fine and you could then have a defined phrase for it, but it needs to be specified for each place where TLS is used. The text at the end of p15 is almost exactly what's needed, and would be if you said which ciphersuites are MUSTs. I think you might need to pick ciphersuites for each version if you want some combination of tls1.0 and tls1.2 and need server auth at least. (3) Having a MUST for TLS1.0 and a SHOULD for TLS1.2 is going to generate a DISCUSS or two. I think you really need to justify that in the Document and PROTO write up if you want to stick with the current choices. I personally would prefer if those were swapped myself, that is have a MUST for the latest version of TLS (TLS1.2) and a MAY/SHOULD for TLS 1.0. In addition to taking care of process concerns, there is also the recent TLS chosen plaintext attack where TLS1.2 has no problem but TLS1.0 does. (This differs from (2) above, since the former is almost editorial, but I guess this one needs to go to the WG.) (4) The response_type description in 3.1.1 is unclear. You say it MUST be one of various values, but then that it can be a space separated list of values. When 1 value is provided, it doesn't say what that means, it only says that the order is irrelevant. (It could mean any of these or all of these for example, both are order independent, but are not the same.) I suggest adding a sentence to say that code token means please send both if that's what it means. (5) How does a client implement the MUST in the last sentence of 3.1.2.3? I don't see anything here or in 10.15 that says how to do this. I guess ideally, you'd just need a reference to somewhere else in the doc or to something else, but I do think you need something since you've made this a MUST ensure rule for clients. Adding a sentence/short paragraph here or in 10.15 with some typical/good ways to ensure this would be fine. (6) In 7.1 what does it mean to say that the client MUST NOT use the access token if it doesn't trust the token type? I don't know what code I'd write there in a client. Maybe s/trust/support/ or s/trust/understand/ would fix this. (7) Doesn't 7.1 need to say which token types are MTI so that we get interop? I think I'd like to see mac being a MUST and bearer being a MAY but regardless of my preference, I don't think you can be silent on this. One way to do this would be to mandate that the client MUST support mac and MAY support bearer but to allow the server to choose which token types they support. And as a consequence one or both of the mac/bearer drafts need to end up as normative I think. (8) 10.3 says access tokens MUST be kept confidential in transit. Does that not mean that non-anonymous TLS is a MUST? If so, then saying that clearly here would be good. If not, then saying what's really meant clearly is needed. (Same point for refresh tokens in 10.4.) (9) 10.5 says effort should be made to keep codes confidential, but I expect that'll generate AD comments - that's just a bit too vague - what do you really mean there? (10) 10.10 has an impossible requirement - you cannot stop/prevent attackers guessing, but you can ensure that such guessing is futile. Can you not be a bit more specific about a reasonable level of entropy here? I'd say 10 bits is not enough, 128 is, and there may be a good level to at least RECOMMEND (e.g. maybe N bits if rate limiting can effectively prevent 2^(N/2) guesses going undetected? I'm not recommending an N myself here, but rather that the WG consider picking one or else justify not picking one. (The same comment applies to the term non-guessable as used in 10.12 and maybe elsewhere as well.) (11) Section 11 says a couple of times that the apps ADs are the appeal chain -
