Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg

[Kathleen Moriarty]

On Wed, Feb 18, 2015 at 4:45 PM, Sam Hartman  wrote:

> > "Kathleen" == Kathleen Moriarty 
> writes:
>
> Kathleen> registry, but setting HTTP Basic as the default seems like
> Kathleen> a really bad choice. HOBA is on it's way to becoming an
> Kathleen> RFC from the HTTPAuth working group.  HTTPAuth also has an
> Kathleen> updated version of Basic that is in IETF last call, but I
> Kathleen> know you are pointing to the OAuth 2.0 document, so it
> Kathleen> would be that document that gets updated and not this
> Kathleen> draft.  The new version of HTTP Basic fixes some
> Kathleen> internationalization problems and spells out the security
> Kathleen> issues much more clearly, so it probably doesn't matter
> Kathleen> too much to update the reference, but maybe makes it more
> Kathleen> clear that basic is not a secure form of authentication.
> Kathleen> Can you provide some justification as to why this is okay
> Kathleen> to set basic as the default and add that to the draft?
> Kathleen> Section 2.3.1 of OAuth 2.0 just says this MUST be
> Kathleen> implemented, but that any HTTP schemes can be used.  Why
> Kathleen> not register another method and use that instead as the
> Kathleen> default?  You could use digest and there is library
> Kathleen> support.  It's not a great answer, but slightly better
> Kathleen> than passwords with basic.  You could register HOBA and
> Kathleen> use that instead, the only downside is limited library
> Kathleen> support at the moment.
>
>
> I'm disappointed to be reading the above, particularly the last
> sentence, today.
> I'd hope that we'd have a better wide-spread understanding of the issues
> in deploying credentials by this point.
>
> Yes, you absolutely can choose whatever you like as the authentication
> scheme for a single-use account.  If my account will only be used with a
> particularly dynamically registration then I probably can get away with
> choosing whatever I want as a default authentication and statements like
> "the only down-side will be limited library availability," will be true.
>
> However, a lot of deployments re-use accounts.  That is, the
> deploymentwill allow some form of single sign-on.  The same account may
> be used for an oauth dynamic registration as well as a bunch of other
> things.
> Even more of an issue, the backend database of credentials may already
> exist and may not be defined by this particular application.
>
> Digest is absolutely impossible to use if I've got a database of  NTLM
> hashes (read Active Directory) that are my credentials.  (In the
> particular case of AD and digest, you probably have a solution if you
> are using Microsoft's implementation.)
> However, if I've got some relational (or nosql) database storing hashes
> that  I've been accumulating as I sign up users for the last few years,
> I can only use authentication schemes compatible with those hashes.
>
>
> The huge deployment advantage of basic is that if you present me the
> password, I can match against whatever I have on the backend.  I can try
> various normalizations, try code-page conversions, rehash, whatever.
> If your client implements scram, and I have NTLM, we're never going to
> be able to talk.  Me implementing scram doesn't help if that's not how
> I've got credentials stored.
>
> Put another way, end protocols like this are not the right place to
> fight passwords.  You transition credential technologies at the
> deployment level, not at the protocol level.
>
> For interoperability in something like this we're likely going to do no
> better than basic.  Anything else from httpauth will fall squarely into
> the category of MUST BUT WE KNOW YOU WON't for some significant
> deployments.
>
> What I've said above doesn't apply particularly to protocols where the
> credentials will not be reused.
>
> I'd be happy to talk some time about strategies for giving deployments
> the tools they need to move their credential interface away from
> passwords, but it does need to be thought of as a deployment issue
> crossing all the applications and protocols that a set of credentials
> use.  This is the wrong place to fight that battle.
>

Sam,

You may have missed part of the thread.  I did not ask the WG to fix it
here, just noted that I don't like that passwords is the best that we can
do and there is no other more secure option registered.  The WG will take a
look at this and see if other options are feasible.  An approach Justin is
working on was provided, but I haven't had time to read that yet.  If
something gets done, it was already agreed that it would be in a separate
draft, I did not ask for it to be done here.

Thanks,
Kathleen

>
> --Sam
>



-- 

Best regards,
Kathleen
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg

[Sam Hartman]

> "Kathleen" == Kathleen Moriarty  writes:

Kathleen> registry, but setting HTTP Basic as the default seems like
Kathleen> a really bad choice. HOBA is on it's way to becoming an
Kathleen> RFC from the HTTPAuth working group.  HTTPAuth also has an
Kathleen> updated version of Basic that is in IETF last call, but I
Kathleen> know you are pointing to the OAuth 2.0 document, so it
Kathleen> would be that document that gets updated and not this
Kathleen> draft.  The new version of HTTP Basic fixes some
Kathleen> internationalization problems and spells out the security
Kathleen> issues much more clearly, so it probably doesn't matter
Kathleen> too much to update the reference, but maybe makes it more
Kathleen> clear that basic is not a secure form of authentication.
Kathleen> Can you provide some justification as to why this is okay
Kathleen> to set basic as the default and add that to the draft?
Kathleen> Section 2.3.1 of OAuth 2.0 just says this MUST be
Kathleen> implemented, but that any HTTP schemes can be used.  Why
Kathleen> not register another method and use that instead as the
Kathleen> default?  You could use digest and there is library
Kathleen> support.  It's not a great answer, but slightly better
Kathleen> than passwords with basic.  You could register HOBA and
Kathleen> use that instead, the only downside is limited library
Kathleen> support at the moment.  


I'm disappointed to be reading the above, particularly the last
sentence, today.
I'd hope that we'd have a better wide-spread understanding of the issues
in deploying credentials by this point.

Yes, you absolutely can choose whatever you like as the authentication
scheme for a single-use account.  If my account will only be used with a
particularly dynamically registration then I probably can get away with
choosing whatever I want as a default authentication and statements like
"the only down-side will be limited library availability," will be true.

However, a lot of deployments re-use accounts.  That is, the
deploymentwill allow some form of single sign-on.  The same account may
be used for an oauth dynamic registration as well as a bunch of other
things.
Even more of an issue, the backend database of credentials may already
exist and may not be defined by this particular application.

Digest is absolutely impossible to use if I've got a database of  NTLM
hashes (read Active Directory) that are my credentials.  (In the
particular case of AD and digest, you probably have a solution if you
are using Microsoft's implementation.)
However, if I've got some relational (or nosql) database storing hashes
that  I've been accumulating as I sign up users for the last few years,
I can only use authentication schemes compatible with those hashes.


The huge deployment advantage of basic is that if you present me the
password, I can match against whatever I have on the backend.  I can try
various normalizations, try code-page conversions, rehash, whatever.
If your client implements scram, and I have NTLM, we're never going to
be able to talk.  Me implementing scram doesn't help if that's not how
I've got credentials stored.

Put another way, end protocols like this are not the right place to
fight passwords.  You transition credential technologies at the
deployment level, not at the protocol level.

For interoperability in something like this we're likely going to do no
better than basic.  Anything else from httpauth will fall squarely into
the category of MUST BUT WE KNOW YOU WON't for some significant
deployments.

What I've said above doesn't apply particularly to protocols where the
credentials will not be reused.

I'd be happy to talk some time about strategies for giving deployments
the tools they need to move their credential interface away from
passwords, but it does need to be thought of as a deployment issue
crossing all the applications and protocols that a set of credentials
use.  This is the wrong place to fight that battle.

--Sam

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

Re: [OAUTH-WG] Shepherd Writeup for draft-ietf-oauth-spop-06.txt

[John Bradley]

It was Google that wanted S256 to be mandatory for the AS to support.  That 
makes it easier for the client. 

S256 is relatively new so not being supported yet is not surprising. 

Sent from my iPhone

> On Feb 18, 2015, at 12:15 PM, Torsten Lodderstedt  
> wrote:
> 
> We don't plan to support s256 
> 
> Basically, I don't see a need to. Plain already mitigates the threat, 
> spop/tcse had been designed to mitigate - an app intercepting the code 
> response of a public client.
> 
> Am 18. Februar 2015 18:33:17 MEZ, schrieb Hannes Tschofenig 
> :
>> 
>> Thanks Brian for pointing me to Section 4.4.1 and to the MTI for "S256".
>> While this is good from a security point of view I am wondering whether
>> anyone is actually compliant to the specification. Neither PingIdentity
>> nor DT implements the S256 transform, if I understood that correctly.
>> Are you guys going planning to update your implementations?
>> 
>> Ciao
>> Hannes
>> 
>>> On 02/18/2015 05:45 PM, Brian Campbell wrote:
>>>  There's a bit of MTI talk tucked into
>>>  https://tools.ietf.org/html/draft-ietf-oauth-spop-10#section-4.4.1 that
>>>  perhaps needs to be expanded and/or placed somewhere else.
>>>  
>>>  On Wed, Feb 18, 2015 at 8:33 AM, Hannes Tschofenig
>>>  >> > wrote:
>>>  
>>>  Thanks for the info, Torsten.
>>>  
>>>  Your feedback raises an interesting question, namely what functionality
>>>  the parties have to implement to claim conformance to the 
>>> specification.
>>>  
>>>  Quickly scanning through the specification didn't tell me whether it is
>>>  OK to just implement the plain mode or whether both modes are
>>>  mandatory-to-implement. We have to say something about this.
>>>  
>>>  Ciao
>>>  Hannes
>>>  
>>>  
>>>  On 02/18/2015 02:16 PM, tors...@lodderstedt.net
>>>   wrote:
  Hi Hannes,
 
  our implementation supports the "plain" mode only. We just verified
  compliance of our implementation with the current spec. As the only
  deviation, we do not enforce the
 minimum length of 43 characters
>>>  of the
  code verifier.
 
  kind regards,
  Torsten.
 
  Am 17.02.2015 17:48, schrieb Hannes Tschofenig:
>  Hi Torsten,
> 
>  does this mean that your implementation is not compliant with the
>  current version anymore or that you haven't had time to verify
>>>  whether
>  there are differences to the earlier version?
> 
>  Ciao
>  Hannes
> 
> 
>  On 01/31/2015 05:34 PM, Torsten
> Lodderstedt wrote:
>>  Deutsche Telekom also implemented an early version of the draft last
>>  year.
>> 
>> 
>> 
>>  Am 30.01.2015 um 18:50 schrieb Brian Campbell
>>  mailto:bcampb...@pingidentity.com>
>>>  >>  >>:
>> 
>>> 
>>>  On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig
>>>  mailto:hannes.tschofe...@gmx.net>
>>>  >>  >> wrote:
>>> 
>>> 
>>>  1) What implementations of the spec are you aware of?
>>> 
>>> 
>>>  We have an AS side implementation of an earlier draft that was
>>>  released in June of last year:
>>>  
>>> http://documentation.pingidentity.com/pages/viewpage.action?pageId=26706844
>>> 
>>> 
>>>  OAuth mailing list
>>>  OAuth@ietf.org  >>  >
>>>  https://www.ietf.org/mailman/listinfo/oauth
> 
> -- 
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
> ___
> 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] Shepherd Writeup for draft-ietf-oauth-spop-06.txt

[Torsten Lodderstedt]

We don't plan to support s256 

Basically, I don't see a need to. Plain already mitigates the threat, spop/tcse 
had been designed to mitigate - an app intercepting the code response of a 
public client.

Am 18. Februar 2015 18:33:17 MEZ, schrieb Hannes Tschofenig 
:
>Thanks Brian for pointing me to Section 4.4.1 and to the MTI for
>"S256".
>While this is good from a security point of view I am wondering whether
>anyone is actually compliant to the specification. Neither PingIdentity
>nor DT implements the S256 transform, if I understood that correctly.
>Are you guys going planning to update your implementations?
>
>Ciao
>Hannes
>
>On 02/18/2015 05:45 PM, Brian Campbell wrote:
>> There's a bit of MTI talk tucked into
>> https://tools.ietf.org/html/draft-ietf-oauth-spop-10#section-4.4.1
>that
>> perhaps needs to be expanded and/or placed somewhere else.
>> 
>> On Wed, Feb 18, 2015 at 8:33 AM, Hannes Tschofenig
>> mailto:hannes.tschofe...@gmx.net>> wrote:
>> 
>> Thanks for the info, Torsten.
>> 
>> Your feedback raises an interesting question, namely what
>functionality
>> the parties have to implement to claim conformance to the
>specification.
>> 
>> Quickly scanning through the specification didn't tell me whether
>it is
>> OK to just implement the plain mode or whether both modes are
>> mandatory-to-implement. We have to say something about this.
>> 
>> Ciao
>> Hannes
>> 
>> 
>> On 02/18/2015 02:16 PM, tors...@lodderstedt.net
>>  wrote:
>> > Hi Hannes,
>> >
>> > our implementation supports the "plain" mode only. We just
>verified
>> > compliance of our implementation with the current spec. As the
>only
>> > deviation, we do not enforce the minimum length of 43
>characters
>> of the
>> > code verifier.
>> >
>> > kind regards,
>> > Torsten.
>> >
>> > Am 17.02.2015 17:48, schrieb Hannes Tschofenig:
>> >> Hi Torsten,
>> >>
>> >> does this mean that your implementation is not compliant with
>the
>> >> current version anymore or that you haven't had time to verify
>> whether
>> >> there are differences to the earlier version?
>> >>
>> >> Ciao
>> >> Hannes
>> >>
>> >>
>> >> On 01/31/2015 05:34 PM, Torsten Lodderstedt wrote:
>> >>> Deutsche Telekom also implemented an early version of the
>draft last
>> >>> year.
>> >>>
>> >>>
>> >>>
>> >>> Am 30.01.2015 um 18:50 schrieb Brian Campbell
>> >>> 
>> > >>:
>> >>>
>> 
>>  On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig
>>  
>> > >> wrote:
>> 
>> 
>>  1) What implementations of the spec are you aware of?
>> 
>> 
>>  We have an AS side implementation of an earlier draft that
>was
>>  released in June of last year:
>> 
>>
>http://documentation.pingidentity.com/pages/viewpage.action?pageId=26706844
>> 
>>  ___
>>  OAuth mailing list
>>  OAuth@ietf.org 
>> >
>>  https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg

[Hannes Tschofenig]

Hi Justin, Hi John,

I believe that provisioning a client with a unique id (which is what a
client id/client secret is) allows some form of linkability. While it
may be possible to associate the client to a specific user I could very
well imagine that the correlation between activities from a user and
those from the client (particularly when the client is running on the
user's device) is quite possible.

Ciao
Hannes

On 02/18/2015 06:37 PM, Justin Richer wrote:
> I’ll incorporate this feedback into another draft, to be posted by the
> end of the week. Thanks everyone!
> 
>  — Justin
> 
>> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty
>> > > wrote:
>>
>>
>>
>> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley > > wrote:
>>
>> snip
>>> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
>>> >> > wrote:
>>>
>>> > The client_id *could* be short lived, but they usually aren't. I 
>>> don't see any particular logging or tracking concerns using a dynamic OAuth 
>>> client above using any other piece of software, ever. As such, I don't 
>>> think it requires special calling out here.
>>>
>>>
>>> Help me understand why there should not be text that shows this
>>> is not an issue or please propose some text.  This is bound to
>>> come up in IESG reviews if not addressed up front. 
>>>
>>>
>>
>> The client_id is used to communicate to the Authorization server
>> to get a code or refresh token.  Those tokens uniquely identify
>> the user from a privacy perspective. 
>> It is the access tokens that are sent to the RS and those can and
>> should be rotated, but the client)id is not sent to the RS in
>> OAuth as part of the spec. 
>>
>> If you did rotate the client_id then the AS would track it across
>> rotations, so it wouldn’t really achieve anything.
>>
>> One thing we don’t do is allow the client to specify the
>> client_id, that could allow correlation of the client across
>> multiple AS and that might be a privacy issue, but we don’t allow it.
>>
>>
>> Thanks, John.  It may be helpful to add in this explanation unless
>> there is some reason not to? 
>>
>>
>> John B.
>>
>>
>>
>>
>> -- 
>>
>> Best regards,
>> Kathleen
>> ___
>> 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
> 



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg

[Hannes Tschofenig]

Hi Justin, Hi John,

I believe that provisioning a client with a unique id (which is what a
client id/client secret is) allows some form of linkability. While it
may be possible to associate the client to a specific user I could very
well imagine that the correlation between activities from a user and
those from the client (particularly when the client is running on the
user's device) is quite possible.

Ciao
Hannes

On 02/18/2015 06:37 PM, Justin Richer wrote:
> I’ll incorporate this feedback into another draft, to be posted by the
> end of the week. Thanks everyone!
> 
>  — Justin
> 
>> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty
>> > > wrote:
>>
>>
>>
>> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley > > wrote:
>>
>> snip
>>> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty
>>> >> > wrote:
>>>
>>> > The client_id *could* be short lived, but they usually aren't. I 
>>> don't see any particular logging or tracking concerns using a dynamic OAuth 
>>> client above using any other piece of software, ever. As such, I don't 
>>> think it requires special calling out here.
>>>
>>>
>>> Help me understand why there should not be text that shows this
>>> is not an issue or please propose some text.  This is bound to
>>> come up in IESG reviews if not addressed up front. 
>>>
>>>
>>
>> The client_id is used to communicate to the Authorization server
>> to get a code or refresh token.  Those tokens uniquely identify
>> the user from a privacy perspective. 
>> It is the access tokens that are sent to the RS and those can and
>> should be rotated, but the client)id is not sent to the RS in
>> OAuth as part of the spec. 
>>
>> If you did rotate the client_id then the AS would track it across
>> rotations, so it wouldn’t really achieve anything.
>>
>> One thing we don’t do is allow the client to specify the
>> client_id, that could allow correlation of the client across
>> multiple AS and that might be a privacy issue, but we don’t allow it.
>>
>>
>> Thanks, John.  It may be helpful to add in this explanation unless
>> there is some reason not to? 
>>
>>
>> John B.
>>
>>
>>
>>
>> -- 
>>
>> Best regards,
>> Kathleen
>> ___
>> 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
> 



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg

[Justin Richer]

I’ll incorporate this feedback into another draft, to be posted by the end of 
the week. Thanks everyone!

 — Justin

> On Feb 18, 2015, at 10:30 AM, Kathleen Moriarty 
>  wrote:
> 
> 
> 
> On Wed, Feb 18, 2015 at 10:07 AM, John Bradley  > wrote:
> snip
>> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty 
>> mailto:kathleen.moriarty.i...@gmail.com>> 
>> wrote:
>> 
>> > The client_id *could* be short lived, but they usually aren't. I don't see 
>> > any particular logging or tracking concerns using a dynamic OAuth client 
>> > above using any other piece of software, ever. As such, I don't think it 
>> > requires special calling out here.
>> 
>> Help me understand why there should not be text that shows this is not an 
>> issue or please propose some text.  This is bound to come up in IESG reviews 
>> if not addressed up front. 
>> 
> 
> The client_id is used to communicate to the Authorization server to get a 
> code or refresh token.  Those tokens uniquely identify the user from a 
> privacy perspective. 
> It is the access tokens that are sent to the RS and those can and should be 
> rotated, but the client)id is not sent to the RS in OAuth as part of the 
> spec. 
> 
> If you did rotate the client_id then the AS would track it across rotations, 
> so it wouldn’t really achieve anything.
> 
> One thing we don’t do is allow the client to specify the client_id, that 
> could allow correlation of the client across multiple AS and that might be a 
> privacy issue, but we don’t allow it.
> 
> Thanks, John.  It may be helpful to add in this explanation unless there is 
> some reason not to? 
> 
> John B.
> 
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen
> ___
> 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] Shepherd Writeup for draft-ietf-oauth-spop-06.txt

[Hannes Tschofenig]

Thanks Brian for pointing me to Section 4.4.1 and to the MTI for "S256".
While this is good from a security point of view I am wondering whether
anyone is actually compliant to the specification. Neither PingIdentity
nor DT implements the S256 transform, if I understood that correctly.
Are you guys going planning to update your implementations?

Ciao
Hannes

On 02/18/2015 05:45 PM, Brian Campbell wrote:
> There's a bit of MTI talk tucked into
> https://tools.ietf.org/html/draft-ietf-oauth-spop-10#section-4.4.1 that
> perhaps needs to be expanded and/or placed somewhere else.
> 
> On Wed, Feb 18, 2015 at 8:33 AM, Hannes Tschofenig
> mailto:hannes.tschofe...@gmx.net>> wrote:
> 
> Thanks for the info, Torsten.
> 
> Your feedback raises an interesting question, namely what functionality
> the parties have to implement to claim conformance to the specification.
> 
> Quickly scanning through the specification didn't tell me whether it is
> OK to just implement the plain mode or whether both modes are
> mandatory-to-implement. We have to say something about this.
> 
> Ciao
> Hannes
> 
> 
> On 02/18/2015 02:16 PM, tors...@lodderstedt.net
>  wrote:
> > Hi Hannes,
> >
> > our implementation supports the "plain" mode only. We just verified
> > compliance of our implementation with the current spec. As the only
> > deviation, we do not enforce the minimum length of 43 characters
> of the
> > code verifier.
> >
> > kind regards,
> > Torsten.
> >
> > Am 17.02.2015 17:48, schrieb Hannes Tschofenig:
> >> Hi Torsten,
> >>
> >> does this mean that your implementation is not compliant with the
> >> current version anymore or that you haven't had time to verify
> whether
> >> there are differences to the earlier version?
> >>
> >> Ciao
> >> Hannes
> >>
> >>
> >> On 01/31/2015 05:34 PM, Torsten Lodderstedt wrote:
> >>> Deutsche Telekom also implemented an early version of the draft last
> >>> year.
> >>>
> >>>
> >>>
> >>> Am 30.01.2015 um 18:50 schrieb Brian Campbell
> >>> mailto:bcampb...@pingidentity.com>
>  >>:
> >>>
> 
>  On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig
>  mailto:hannes.tschofe...@gmx.net>
>  >> wrote:
> 
> 
>  1) What implementations of the spec are you aware of?
> 
> 
>  We have an AS side implementation of an earlier draft that was
>  released in June of last year:
> 
> 
> http://documentation.pingidentity.com/pages/viewpage.action?pageId=26706844
> 
>  ___
>  OAuth mailing list
>  OAuth@ietf.org   >
>  https://www.ietf.org/mailman/listinfo/oauth
> 
> 



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Shepherd Writeup for draft-ietf-oauth-spop-06.txt

[Brian Campbell]

There's a bit of MTI talk tucked into
https://tools.ietf.org/html/draft-ietf-oauth-spop-10#section-4.4.1 that
perhaps needs to be expanded and/or placed somewhere else.

On Wed, Feb 18, 2015 at 8:33 AM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:

> Thanks for the info, Torsten.
>
> Your feedback raises an interesting question, namely what functionality
> the parties have to implement to claim conformance to the specification.
>
> Quickly scanning through the specification didn't tell me whether it is
> OK to just implement the plain mode or whether both modes are
> mandatory-to-implement. We have to say something about this.
>
> Ciao
> Hannes
>
>
> On 02/18/2015 02:16 PM, tors...@lodderstedt.net wrote:
> > Hi Hannes,
> >
> > our implementation supports the "plain" mode only. We just verified
> > compliance of our implementation with the current spec. As the only
> > deviation, we do not enforce the minimum length of 43 characters of the
> > code verifier.
> >
> > kind regards,
> > Torsten.
> >
> > Am 17.02.2015 17:48, schrieb Hannes Tschofenig:
> >> Hi Torsten,
> >>
> >> does this mean that your implementation is not compliant with the
> >> current version anymore or that you haven't had time to verify whether
> >> there are differences to the earlier version?
> >>
> >> Ciao
> >> Hannes
> >>
> >>
> >> On 01/31/2015 05:34 PM, Torsten Lodderstedt wrote:
> >>> Deutsche Telekom also implemented an early version of the draft last
> >>> year.
> >>>
> >>>
> >>>
> >>> Am 30.01.2015 um 18:50 schrieb Brian Campbell
> >>> mailto:bcampb...@pingidentity.com>>:
> >>>
> 
>  On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig
>  mailto:hannes.tschofe...@gmx.net>> wrote:
> 
> 
>  1) What implementations of the spec are you aware of?
> 
> 
>  We have an AS side implementation of an earlier draft that was
>  released in June of last year:
> 
> http://documentation.pingidentity.com/pages/viewpage.action?pageId=26706844
> 
>  ___
>  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-spop-10

[Brian Campbell]

On Wed, Feb 18, 2015 at 7:38 AM, John Bradley  wrote:

>
>
> I don’t remember precisely , but I may be the one responsible for the for
> the 2^(-128) value for code.
>
>
The archives have a more precise memory
http://www.ietf.org/mail-archive/web/oauth/current/msg03844.html ;)
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-spop-10

[Bill Mills]

I was OK with SHOULD because there's no firm measure of "enough entropy".  
Whether it's SHOULD or MUST is moot without some way to quantify it. 

 On Wednesday, February 18, 2015 1:27 AM, Nat Sakimura 
 wrote:
   

 Hi Hannes, 

The reason I have put SHOULD there instead of MUST is 
that there may be a valid reason not to in a controlled 
environment, and it does not interfere the interoperability.
The deployment may opt to use other control than entropy, 
and SHOULD allows it while MUST does not. 

Having said that, if the WG is OK with a MUST there, 
I am fine with incorporating the proposed change. 

Cheers, 

Nat


On Wed, 18 Feb 2015 09:43:30 +0100
Hannes Tschofenig  wrote:

> Hi Nat,
> 
> thanks for the quick response.
> 
> I was hoping to see a statement like "The code verifier MUST have
> enough entropy to make it impractical to guess the value." in the
> text rather than the SHOULD. Given all the other statements in the
> draft I am not sure what the should actually means. Under what
> conditions would an implementer not provide enough entropy to make
> guessing impractical?
> 
> Ciao
> Hannes
> 
> On 02/18/2015 05:13 AM, Nat Sakimura wrote:
> > Hi Hannes, 
> > 
> > I hereby confirm that I have submit the draft  in full conformance
> > with the  provisions of BCP 78 and BCP 79.
> > 
> > Re: Security Consideration (7.1) and section 4.1
> > 
> > The first part of the 7.1 is a non-normative prose explaining that
> > the implementers got to make sure that the code verifier is hard to
> > guessed or modeled. In a way, this is laying out the basic security
> > property requirment on the code verifier. 
> > 
> > Then, it goes onto the implementation guideance that one need to
> > use a cryptographic random number generator instead of relying on a
> > rand() in some language that are  not cryptographically random to
> > generate 32-octet sequence. The same text is in 4.1 as well. 
> > 
> > We did not copy "code verifier SHOULD have enough entropy to make
> > it impractical to guess the value" here because that looked
> > needlessly repeating, but if you want, I have no objection in
> > adding it to 7.1. 
> > 
> > Alternatively, in 7.1, after explaining the rationale, we can just
> > point to 4.1 for the control and implementation guidance. 
> > 
> > Re: 32-octet
> > 
> > We chose it because we are using SHA256 in generating the code
> > challange. Having more entropy does not help us here, while having
> > less octets increases the risk. 
> > 
> > Best, 
> > 
> > Nat 
> > 
> > 
> > 
> > On Tue, 17 Feb 2015 17:56:33 +0100
> > Hannes Tschofenig  wrote:
> > 
> >> Hi Nat, John, Naveen,
> >>
> >> thanks a lot for your work on the document.
> >>
> >> I still need responses to this mail to complete the shepherd
> >> writeup:
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
> >>
> >> I definitely need the IPR confirmation.
> >>
> >> It would also be helpful to have someone who implemented the
> >> specification as it currently is. I asked Brian and Thorsten for
> >> clarification regarding their statements that they implemented
> >> earlier versions of the spec.
> >>
> >> As a final remark I still believe that the text regarding the
> >> randomness is still a bit inconsistent. Here are two examples:
> >>
> >> 1) In the Security Consideration you write that "The security model
> >> relies on the fact that the code verifier is not learned or
> >> guessed by the attacker.  It is vitally important to adhere to
> >> this principle. "
> >>
> >> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
> >> have enough entropy to make it impractical to guess the value.  It
> >> is RECOMMENDED that the output of a suitable random number
> >> generator be used to create a 32-octet sequence."
> >>
> >> There is clearly a long way from a SHOULD have enough entropy to
> >> the text in the security consideration section where you ask for
> >> 32 bytes entropy.
> >>
> >> It is also not clear why you ask for 32 bytes of entropy in
> >> particular.
> >>
> >> Ciao
> >> Hannes
> >>
> > 
> > 
> 


-- 
Nat Sakimura (n-sakim...@nri.co.jp)
Nomura Research Institute, Ltd. 

本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信
することを意図しております。意図された受取人以外の方によるこれらの情報の
開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メール
を受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受
信されたメールを削除していただきますようお願い致します。 PLEASE READ:
The information contained in this e-mail is confidential and intended
for the named recipient(s) only. If you are not an intended recipient
of this e-mail, you are hereby notified that any review, dissemination,
distribution or duplication of this message is strictly prohibited. If
you have received this message in error, please notify the sender
immediately and delete your copy from your system.

___
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/o

Re: [OAUTH-WG] Shepherd Writeup for draft-ietf-oauth-spop-06.txt

[Hannes Tschofenig]

Thanks for the info, Torsten.

Your feedback raises an interesting question, namely what functionality
the parties have to implement to claim conformance to the specification.

Quickly scanning through the specification didn't tell me whether it is
OK to just implement the plain mode or whether both modes are
mandatory-to-implement. We have to say something about this.

Ciao
Hannes


On 02/18/2015 02:16 PM, tors...@lodderstedt.net wrote:
> Hi Hannes,
> 
> our implementation supports the "plain" mode only. We just verified
> compliance of our implementation with the current spec. As the only
> deviation, we do not enforce the minimum length of 43 characters of the
> code verifier.
> 
> kind regards,
> Torsten.
> 
> Am 17.02.2015 17:48, schrieb Hannes Tschofenig:
>> Hi Torsten,
>>
>> does this mean that your implementation is not compliant with the
>> current version anymore or that you haven't had time to verify whether
>> there are differences to the earlier version?
>>
>> Ciao
>> Hannes
>>
>>
>> On 01/31/2015 05:34 PM, Torsten Lodderstedt wrote:
>>> Deutsche Telekom also implemented an early version of the draft last
>>> year.
>>>
>>>
>>>
>>> Am 30.01.2015 um 18:50 schrieb Brian Campbell
>>> mailto:bcampb...@pingidentity.com>>:
>>>

 On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig
 mailto:hannes.tschofe...@gmx.net>> wrote:


 1) What implementations of the spec are you aware of?


 We have an AS side implementation of an earlier draft that was
 released in June of last year:
 http://documentation.pingidentity.com/pages/viewpage.action?pageId=26706844

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



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg

[Kathleen Moriarty]

On Wed, Feb 18, 2015 at 10:07 AM, John Bradley  wrote:

> snip
>
> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty <
> kathleen.moriarty.i...@gmail.com> wrote:
>
> > The client_id *could* be short lived, but they usually aren't. I don't
>> see any particular logging or tracking concerns using a dynamic OAuth
>> client above using any other piece of software, ever. As such, I don't
>> think it requires special calling out here.
>>
>
> Help me understand why there should not be text that shows this is not an
> issue or please propose some text.  This is bound to come up in IESG
> reviews if not addressed up front.
>
>>
>>
> The client_id is used to communicate to the Authorization server to get a
> code or refresh token.  Those tokens uniquely identify the user from a
> privacy perspective.
> It is the access tokens that are sent to the RS and those can and should
> be rotated, but the client)id is not sent to the RS in OAuth as part of the
> spec.
>
> If you did rotate the client_id then the AS would track it across
> rotations, so it wouldn’t really achieve anything.
>
> One thing we don’t do is allow the client to specify the client_id, that
> could allow correlation of the client across multiple AS and that might be
> a privacy issue, but we don’t allow it.
>

Thanks, John.  It may be helpful to add in this explanation unless there is
some reason not to?

>
> John B.
>
>


-- 

Best regards,
Kathleen
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg

[John Bradley]

snip
> On Feb 18, 2015, at 6:46 AM, Kathleen Moriarty 
>  wrote:
> 
> > The client_id *could* be short lived, but they usually aren't. I don't see 
> > any particular logging or tracking concerns using a dynamic OAuth client 
> > above using any other piece of software, ever. As such, I don't think it 
> > requires special calling out here.
> 
> Help me understand why there should not be text that shows this is not an 
> issue or please propose some text.  This is bound to come up in IESG reviews 
> if not addressed up front. 
> 

The client_id is used to communicate to the Authorization server to get a code 
or refresh token.  Those tokens uniquely identify the user from a privacy 
perspective. 
It is the access tokens that are sent to the RS and those can and should be 
rotated, but the client)id is not sent to the RS in OAuth as part of the spec. 

If you did rotate the client_id then the AS would track it across rotations, so 
it wouldn’t really achieve anything.

One thing we don’t do is allow the client to specify the client_id, that could 
allow correlation of the client across multiple AS and that might be a privacy 
issue, but we don’t allow it.

John B.



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg

[Kathleen Moriarty]

Hi,


On Mon, Feb 16, 2015 at 6:42 PM, Mike Jones 
wrote:

> A few responses and comments are inline below...
>
> > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
> > Sent: Thursday, February 12, 2015 11:47 AM
> > To: Justin Richer
> > Cc: oauth@ietf.org
> > Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
> >
> >
> > Phil
> >
> > @independentid
> > www.independentid.com
> > phil.h...@oracle.com
> >
> > On Feb 11, 2015, at 8:31 PM, Justin Richer  wrote:
> >
> > Kathleen, thanks for the review. Responses inline, though I'm going to
> let the other authors talk about their sections (deployment org, software
> version, etc) directly.
>

Thanks for the quick responses and sorry about my delay, it's a busy week!


> >
> > On 2/11/2015 6:06 PM, Kathleen Moriarty wrote:
> > Thank you for your work on this draft and sorry for the delay in my
> review.  Before we progress to IETF last call, I'd like to see what we can
> resolve from the list below.   I am looking at the IPR issues to see if we
> can resolve the outstanding questions as well.
> >
> > The Shepherd report says the following:
> >The document shepherd has raised concerns regarding the fuzzy
> description
> >of the actors (deployment organization, software API publisher, client
> >developer) and their impact on the protocol execution. The working
> >group did not seem to worry about these aspects though.
> >
> > I can see the point after reading the draft.  The interactions are
> written much more clearly in the security considerations section than where
> the flows are described.  Can something be done to address these concerns?
> >
> > Section 1.2
> > Deployment Organization definition:
> > I highly recommend replacing the phrase "simple cloud deployment" with a
> description that accurately reflects what is intended.  If that's within a
> single service provider's network, a single data center, or a single hosted
> data center, I think it would be more clear.
> >
> > Section 1.2 nit:
> > Add the word "be" into the following term definition after "may":
> >   Software API Publisher
> >   The organization that defines a particular web accessible API that
> >   may deployed in one or more deployment environments.
> >
> > [deferred to original author of this text Phil et. al for better wording]
> >
> > [Phil] Agreed with Kathleen's suggestion.
>
Thanks!

>
> I also agree that the wording of the definitions could be clarified.
> Justin, do you want to take a first pass at this or would you like to take
> lead on this, Phil?
>
> > Section 2:
> >
> > Why isn't a more secure option offered and set as the default for
> authentication types? I know I've asked this before and the answer was just
> that you can add something to the registry, but setting HTTP Basic as the
> default seems like a really bad choice. HOBA is on it's way to becoming an
> RFC from the HTTPAuth working group.  HTTPAuth also has an updated version
> of Basic that is in IETF last call, but I know you are pointing to the
> OAuth 2.0 document, so it would be that document that gets updated and not
> this draft.  The new version of HTTP Basic fixes some internationalization
> problems and spells out the security issues much more clearly, so it
> probably doesn't matter too much to update the reference, but maybe makes
> it more clear that basic is not a secure form of authentication.
> >
> > Can you provide some justification as to why this is okay to set basic
> as the default and add that to the draft?  Section 2.3.1 of OAuth 2.0 just
> says this MUST be implemented, but that any HTTP schemes can be used.  Why
> not register another method and use that instead as the default?  You could
> use digest and there is library support.  It's not a great answer, but
> slightly better than passwords with basic.  You could register HOBA and use
> that instead, the only downside is limited library support at the moment.
> >
> > It was our intent to document the methods already defined for use with
> OAuth and provide a registration mechanism for distinguishing between them,
> not to create new client authentication mechanisms. Digest and HOBA simply
> aren't defined for use with OAuth clients yet. It would be simple to do:
> put the client id in the "username" field and the client secret in the
> "password" field of both algorithms. However, I don't believe it's a good
> idea to conflate those two goals in a single specification. We actually had
> other, more secure definitions in an earlier draft of this document (using
> a JWT signed with a private key or a JWT signed with a shared key,
> specifically), but those were removed in order to focus on solving just the
> client registration problem. I agree with that decision of the WG.
> >
> > As other methods of client authentication are defined in the OAuth
> ecosystem, they can register as valid values in the registry. I think it
> would be a valuable output of this WG to define other client authentic

Re: [OAUTH-WG] draft-ietf-oauth-spop-10

[John Bradley]

As I stated in my message.  I think for plain having there be a MUST at 256 
bits would be overkill.  

For plain given it is single use like the code is we should probably match it 
to the entropy required for code.

In RFC 6749 we say
The probability of an attacker guessing generated tokens (and other
   credentials not intended for handling by end-users) MUST be less than
   or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160).

So to be consistent I would make plain "MUST be between 16 and 32 octets”

I don’t remember precisely , but I may be the one responsible for the for the 
2^(-128) value for code.  
That was a bit higher than needed if people can really only use code once.   
However the reality is that not all AS properly revoke code after it is used.
That is really hard in a clustered environment.  (There is more than one large 
one so I am not picking on anyone in particular) 

Knowing that in reality an attacker might be able to make a limited number 
attacks before a code time expires there is a fudge factor in the 128bit code 
to still make it plausibly unguessable even in that case.

The same factor would apply to code_verifier other wise I would say 8 octets 
would be sufficient.

 John B.

> On Feb 18, 2015, at 1:50 AM, Nat Sakimura  wrote:
> 
> Is there anyone who has problems changing it to a MUST? 
> On 2015年2月18日(水) at 18:48 Hannes Tschofenig  > wrote:
> I think that the "controlled environment" is a risky idea. I believe we
> should definitely go for a MUST.
> 
> On 02/18/2015 10:26 AM, Nat Sakimura wrote:
> > Hi Hannes,
> >
> > The reason I have put SHOULD there instead of MUST is
> > that there may be a valid reason not to in a controlled
> > environment, and it does not interfere the interoperability.
> > The deployment may opt to use other control than entropy,
> > and SHOULD allows it while MUST does not.
> >
> > Having said that, if the WG is OK with a MUST there,
> > I am fine with incorporating the proposed change.
> >
> > Cheers,
> >
> > Nat
> >
> >
> > On Wed, 18 Feb 2015 09:43:30 +0100
> > Hannes Tschofenig  > > wrote:
> >
> >> Hi Nat,
> >>
> >> thanks for the quick response.
> >>
> >> I was hoping to see a statement like "The code verifier MUST have
> >> enough entropy to make it impractical to guess the value." in the
> >> text rather than the SHOULD. Given all the other statements in the
> >> draft I am not sure what the should actually means. Under what
> >> conditions would an implementer not provide enough entropy to make
> >> guessing impractical?
> >>
> >> Ciao
> >> Hannes
> >>
> >> On 02/18/2015 05:13 AM, Nat Sakimura wrote:
> >>> Hi Hannes,
> >>>
> >>> I hereby confirm that I have submit the draft  in full conformance
> >>> with the  provisions of BCP 78 and BCP 79.
> >>>
> >>> Re: Security Consideration (7.1) and section 4.1
> >>>
> >>> The first part of the 7.1 is a non-normative prose explaining that
> >>> the implementers got to make sure that the code verifier is hard to
> >>> guessed or modeled. In a way, this is laying out the basic security
> >>> property requirment on the code verifier.
> >>>
> >>> Then, it goes onto the implementation guideance that one need to
> >>> use a cryptographic random number generator instead of relying on a
> >>> rand() in some language that are  not cryptographically random to
> >>> generate 32-octet sequence. The same text is in 4.1 as well.
> >>>
> >>> We did not copy "code verifier SHOULD have enough entropy to make
> >>> it impractical to guess the value" here because that looked
> >>> needlessly repeating, but if you want, I have no objection in
> >>> adding it to 7.1.
> >>>
> >>> Alternatively, in 7.1, after explaining the rationale, we can just
> >>> point to 4.1 for the control and implementation guidance.
> >>>
> >>> Re: 32-octet
> >>>
> >>> We chose it because we are using SHA256 in generating the code
> >>> challange. Having more entropy does not help us here, while having
> >>> less octets increases the risk.
> >>>
> >>> Best,
> >>>
> >>> Nat
> >>>
> >>>
> >>>
> >>> On Tue, 17 Feb 2015 17:56:33 +0100
> >>> Hannes Tschofenig  >>> > wrote:
> >>>
>  Hi Nat, John, Naveen,
> 
>  thanks a lot for your work on the document.
> 
>  I still need responses to this mail to complete the shepherd
>  writeup:
>  http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html 
>  
> 
>  I definitely need the IPR confirmation.
> 
>  It would also be helpful to have someone who implemented the
>  specification as it currently is. I asked Brian and Thorsten for
>  clarification regarding their statements that they implemented
>  earlier versions of the spec.
> 
>  As a final remark I still believe that the text regarding the
>  randomness is still a bit inconsistent. Here are two ex

Re: [OAUTH-WG] draft-ietf-oauth-spop-10

[Brian Campbell]

I tend to agree with Torsten here - similar sentiments were (maybe not
well) expressed a few weeks ago:
http://www.ietf.org/mail-archive/web/oauth/current/msg14155.html



On Wed, Feb 18, 2015 at 6:36 AM,  wrote:

>  Hi Nat,
>
> as far as I understand, the length of at least 32 octets is justified for
> S256 only. So limiting the MUST to S256 would be ok (from my perspective).
> I consider a general MUST (which also applies to plain) a to strong
> requirement.
>
> kind regards,
> Torsten.
>
> Am 18.02.2015 10:50, schrieb Nat Sakimura:
>
> Is there anyone who has problems changing it to a MUST?
> On 2015年2月18日(水) at 18:48 Hannes Tschofenig 
> wrote:
>
>> I think that the "controlled environment" is a risky idea. I believe we
>> should definitely go for a MUST.
>>
>> On 02/18/2015 10:26 AM, Nat Sakimura wrote:
>> > Hi Hannes,
>> >
>> > The reason I have put SHOULD there instead of MUST is
>> > that there may be a valid reason not to in a controlled
>> > environment, and it does not interfere the interoperability.
>> > The deployment may opt to use other control than entropy,
>> > and SHOULD allows it while MUST does not.
>> >
>> > Having said that, if the WG is OK with a MUST there,
>> > I am fine with incorporating the proposed change.
>> >
>> > Cheers,
>> >
>> > Nat
>> >
>> >
>> > On Wed, 18 Feb 2015 09:43:30 +0100
>> > Hannes Tschofenig  wrote:
>> >
>> >> Hi Nat,
>> >>
>> >> thanks for the quick response.
>> >>
>> >> I was hoping to see a statement like "The code verifier MUST have
>> >> enough entropy to make it impractical to guess the value." in the
>> >> text rather than the SHOULD. Given all the other statements in the
>> >> draft I am not sure what the should actually means. Under what
>> >> conditions would an implementer not provide enough entropy to make
>> >> guessing impractical?
>> >>
>> >> Ciao
>> >> Hannes
>> >>
>> >> On 02/18/2015 05:13 AM, Nat Sakimura wrote:
>> >>> Hi Hannes,
>> >>>
>> >>> I hereby confirm that I have submit the draft  in full conformance
>> >>> with the  provisions of BCP 78 and BCP 79.
>> >>>
>> >>> Re: Security Consideration (7.1) and section 4.1
>> >>>
>> >>> The first part of the 7.1 is a non-normative prose explaining that
>> >>> the implementers got to make sure that the code verifier is hard to
>> >>> guessed or modeled. In a way, this is laying out the basic security
>> >>> property requirment on the code verifier.
>> >>>
>> >>> Then, it goes onto the implementation guideance that one need to
>> >>> use a cryptographic random number generator instead of relying on a
>> >>> rand() in some language that are  not cryptographically random to
>> >>> generate 32-octet sequence. The same text is in 4.1 as well.
>> >>>
>> >>> We did not copy "code verifier SHOULD have enough entropy to make
>> >>> it impractical to guess the value" here because that looked
>> >>> needlessly repeating, but if you want, I have no objection in
>> >>> adding it to 7.1.
>> >>>
>> >>> Alternatively, in 7.1, after explaining the rationale, we can just
>> >>> point to 4.1 for the control and implementation guidance.
>> >>>
>> >>> Re: 32-octet
>> >>>
>> >>> We chose it because we are using SHA256 in generating the code
>> >>> challange. Having more entropy does not help us here, while having
>> >>> less octets increases the risk.
>> >>>
>> >>> Best,
>> >>>
>> >>> Nat
>> >>>
>> >>>
>> >>>
>> >>> On Tue, 17 Feb 2015 17:56:33 +0100
>> >>> Hannes Tschofenig  wrote:
>> >>>
>>  Hi Nat, John, Naveen,
>> 
>>  thanks a lot for your work on the document.
>> 
>>  I still need responses to this mail to complete the shepherd
>>  writeup:
>>  http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
>> 
>>  I definitely need the IPR confirmation.
>> 
>>  It would also be helpful to have someone who implemented the
>>  specification as it currently is. I asked Brian and Thorsten for
>>  clarification regarding their statements that they implemented
>>  earlier versions of the spec.
>> 
>>  As a final remark I still believe that the text regarding the
>>  randomness is still a bit inconsistent. Here are two examples:
>> 
>>  1) In the Security Consideration you write that "The security model
>>  relies on the fact that the code verifier is not learned or
>>  guessed by the attacker.  It is vitally important to adhere to
>>  this principle. "
>> 
>>  2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
>>  have enough entropy to make it impractical to guess the value.  It
>>  is RECOMMENDED that the output of a suitable random number
>>  generator be used to create a 32-octet sequence."
>> 
>>  There is clearly a long way from a SHOULD have enough entropy to
>>  the text in the security consideration section where you ask for
>>  32 bytes entropy.
>> 
>>  It is also not clear why you ask for 32 bytes of entropy in
>>  particular.
>> 
>>  Ciao
>>  

Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg

[Kathleen Moriarty]

Hi,

On Tue, Feb 17, 2015 at 7:03 PM, Phil Hunt  wrote:

> I’m not sure if this is what Kathleen is after. I think part of the
> background in the current spec is that we were trying to differentiate from
> the large scale success stories OAuth has had in the past like Facebook and
> Google.  When you are a developer trying to build a client for IMAP, a
> standards based protocol, you can’t predict what the endpoints are in
> advance, so obviously an IMAP developer can’t obtain client_ids since they
> can’t predict the future. Nor would it be reasonable to pre-register with
> every possible email deployment in the world.
>

For this, I was just after improved text to clarify the definitions after
seeing the issue in the shepherd writeup and seeing it as I read the
draft.  This looks better to me and I'd like the shepherd to weigh in to
make sure he also thinks the updated definitions clarify the intent for him
as well.

Hannes, what do you think?

>
> NOTE:   We might want to change the terminology from “API” to application
> service or application protocol.  I know some an IETF see the word API and
> associate that exclusively with programming libraries.
>
> deployment organization
>   An administrative security domain under which a software API
> (service) is
>   deployed and protected by an OAuth 2.0 framework. In early OAuth
>   scenarios, the deploying organization was often the same organization
>   that published the API. In these cases the deploying organization
> can have
>  a close relationship with client software developers.  In many other
> cases,
>  the definer of the service may be an independent third-party
> publisher or
>  a standards organization. The client software developer while working
> to
>  a published specification for an API is unable to have a prior
> relationship
>  with the organization deploying the software API (service).
>
> software api publisher
>   The organization that defines a particular web accessible API that
>   may be deployed in one or more deployment environments.  A publisher
>   may be any standards body, commercial, public, private, or open
> source
>   organization that is responsible for publishing and distributing
>   software that may be protected via OAuth 2.0.  In some cases a
>   software API publisher and a client developer may be the same
>   organization. At the time of publication of a web accessible API,
> the software
>  publisher often does not have a prior relationship with deploying
> organizations.
>
>  Client Developer
>   The person or organization that builds a client software package
>   and prepares it for distribution. At the time of building the
> client, the developer
>   is often not aware of who the deploying service provider
> organizations will be.
>   Except when the software API publisher and the deploying
> organization are
>   the same, client developers will need to use dynamic registration
> when they are
>   unable to predict the deployment URLs at “compile time”.
>

Thank you,
Kathleen

>
> Phil
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
> > On Feb 16, 2015, at 4:43 PM, Justin Richer  wrote:
> >
> > To Mike's last question below: I'd like Phil (and others if desired) to
> propose a clarified version of the "deployment organization", "software api
> publisher", and "client developer" if possible. With some text for that in
> hand I can tackle the rest given the feedback below.
> >
> > -- Justin
> >
> > On 2/16/2015 6:42 PM, Mike Jones wrote:
> >> A few responses and comments are inline below...
> >>
> >>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
> >>> Sent: Thursday, February 12, 2015 11:47 AM
> >>> To: Justin Richer
> >>> Cc: oauth@ietf.org
> >>> Subject: Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg
> >>>
> >>>
> >>> Phil
> >>>
> >>> @independentid
> >>> www.independentid.com
> >>> phil.h...@oracle.com
> >>>
> >>> On Feb 11, 2015, at 8:31 PM, Justin Richer  wrote:
> >>>
> >>> Kathleen, thanks for the review. Responses inline, though I'm going to
> let the other authors talk about their sections (deployment org, software
> version, etc) directly.
> >>>
> >>> On 2/11/2015 6:06 PM, Kathleen Moriarty wrote:
> >>> Thank you for your work on this draft and sorry for the delay in my
> review.  Before we progress to IETF last call, I'd like to see what we can
> resolve from the list below.   I am looking at the IPR issues to see if we
> can resolve the outstanding questions as well.
> >>>
> >>> The Shepherd report says the following:
> >>>The document shepherd has raised concerns regarding the fuzzy
> description
> >>>of the actors (deployment organization, software API publisher,
> client
> >>>developer) and their impact on the protocol execution. The working
> >>>group did not seem to worry about these aspects though.
> >>>
> >>> I can see the point after reading the d

Re: [OAUTH-WG] draft-ietf-oauth-spop-10

[torsten]

 

Hi Nat, 

as far as I understand, the length of at least 32 octets is justified
for S256 only. So limiting the MUST to S256 would be ok (from my
perspective). I consider a general MUST (which also applies to plain) a
to strong requirement. 

kind regards,
Torsten. 

Am 18.02.2015 10:50, schrieb Nat Sakimura: 

> Is there anyone who has problems changing it to a MUST? 
> On 2015年2月18日(水) at 18:48 Hannes Tschofenig  wrote:
> 
>> I think that the "controlled environment" is a risky idea. I believe we
>> should definitely go for a MUST.
>> 
>> On 02/18/2015 10:26 AM, Nat Sakimura wrote:
>>> Hi Hannes,
>>> 
>>> The reason I have put SHOULD there instead of MUST is
>>> that there may be a valid reason not to in a controlled
>>> environment, and it does not interfere the interoperability.
>>> The deployment may opt to use other control than entropy,
>>> and SHOULD allows it while MUST does not.
>>> 
>>> Having said that, if the WG is OK with a MUST there,
>>> I am fine with incorporating the proposed change.
>>> 
>>> Cheers,
>>> 
>>> Nat
>>> 
>>> 
>>> On Wed, 18 Feb 2015 09:43:30 +0100
>>> Hannes Tschofenig  wrote:
>>> 
 Hi Nat,
 
 thanks for the quick response.
 
 I was hoping to see a statement like "The code verifier MUST have
 enough entropy to make it impractical to guess the value." in the
 text rather than the SHOULD. Given all the other statements in the
 draft I am not sure what the should actually means. Under what
 conditions would an implementer not provide enough entropy to make
 guessing impractical?
 
 Ciao
 Hannes
 
 On 02/18/2015 05:13 AM, Nat Sakimura wrote:
> Hi Hannes,
> 
> I hereby confirm that I have submit the draft in full conformance
> with the provisions of BCP 78 and BCP 79.
> 
> Re: Security Consideration (7.1) and section 4.1
> 
> The first part of the 7.1 is a non-normative prose explaining that
> the implementers got to make sure that the code verifier is hard to
> guessed or modeled. In a way, this is laying out the basic security
> property requirment on the code verifier.
> 
> Then, it goes onto the implementation guideance that one need to
> use a cryptographic random number generator instead of relying on a
> rand() in some language that are not cryptographically random to
> generate 32-octet sequence. The same text is in 4.1 as well.
> 
> We did not copy "code verifier SHOULD have enough entropy to make
> it impractical to guess the value" here because that looked
> needlessly repeating, but if you want, I have no objection in
> adding it to 7.1.
> 
> Alternatively, in 7.1, after explaining the rationale, we can just
> point to 4.1 for the control and implementation guidance.
> 
> Re: 32-octet
> 
> We chose it because we are using SHA256 in generating the code
> challange. Having more entropy does not help us here, while having
> less octets increases the risk.
> 
> Best,
> 
> Nat
> 
> 
> 
> On Tue, 17 Feb 2015 17:56:33 +0100
> Hannes Tschofenig  wrote:
> 
>> Hi Nat, John, Naveen,
>> 
>> thanks a lot for your work on the document.
>> 
>> I still need responses to this mail to complete the shepherd
>> writeup:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html [1]
>> 
>> I definitely need the IPR confirmation.
>> 
>> It would also be helpful to have someone who implemented the
>> specification as it currently is. I asked Brian and Thorsten for
>> clarification regarding their statements that they implemented
>> earlier versions of the spec.
>> 
>> As a final remark I still believe that the text regarding the
>> randomness is still a bit inconsistent. Here are two examples:
>> 
>> 1) In the Security Consideration you write that "The security model
>> relies on the fact that the code verifier is not learned or
>> guessed by the attacker. It is vitally important to adhere to
>> this principle. "
>> 
>> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
>> have enough entropy to make it impractical to guess the value. It
>> is RECOMMENDED that the output of a suitable random number
>> generator be used to create a 32-octet sequence."
>> 
>> There is clearly a long way from a SHOULD have enough entropy to
>> the text in the security consideration section where you ask for
>> 32 bytes entropy.
>> 
>> It is also not clear why you ask for 32 bytes of entropy in
>> particular.
>> 
>> Ciao
>> Hannes
>> 
> 
> 
 
>>> 
>>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth [2]
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org

Re: [OAUTH-WG] Shepherd Writeup for draft-ietf-oauth-spop-06.txt

[torsten]

Hi Hannes,

our implementation supports the "plain" mode only. We just verified 
compliance of our implementation with the current spec. As the only 
deviation, we do not enforce the minimum length of 43 characters of the 
code verifier.


kind regards,
Torsten.

Am 17.02.2015 17:48, schrieb Hannes Tschofenig:

Hi Torsten,

does this mean that your implementation is not compliant with the
current version anymore or that you haven't had time to verify whether
there are differences to the earlier version?

Ciao
Hannes


On 01/31/2015 05:34 PM, Torsten Lodderstedt wrote:
Deutsche Telekom also implemented an early version of the draft last 
year.




Am 30.01.2015 um 18:50 schrieb Brian Campbell
mailto:bcampb...@pingidentity.com>>:



On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig
mailto:hannes.tschofe...@gmx.net>> wrote:


1) What implementations of the spec are you aware of?


We have an AS side implementation of an earlier draft that was
released in June of last year:
http://documentation.pingidentity.com/pages/viewpage.action?pageId=26706844
___
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-spop-10

[Nat Sakimura]

Is there anyone who has problems changing it to a MUST?
On 2015年2月18日(水) at 18:48 Hannes Tschofenig 
wrote:

> I think that the "controlled environment" is a risky idea. I believe we
> should definitely go for a MUST.
>
> On 02/18/2015 10:26 AM, Nat Sakimura wrote:
> > Hi Hannes,
> >
> > The reason I have put SHOULD there instead of MUST is
> > that there may be a valid reason not to in a controlled
> > environment, and it does not interfere the interoperability.
> > The deployment may opt to use other control than entropy,
> > and SHOULD allows it while MUST does not.
> >
> > Having said that, if the WG is OK with a MUST there,
> > I am fine with incorporating the proposed change.
> >
> > Cheers,
> >
> > Nat
> >
> >
> > On Wed, 18 Feb 2015 09:43:30 +0100
> > Hannes Tschofenig  wrote:
> >
> >> Hi Nat,
> >>
> >> thanks for the quick response.
> >>
> >> I was hoping to see a statement like "The code verifier MUST have
> >> enough entropy to make it impractical to guess the value." in the
> >> text rather than the SHOULD. Given all the other statements in the
> >> draft I am not sure what the should actually means. Under what
> >> conditions would an implementer not provide enough entropy to make
> >> guessing impractical?
> >>
> >> Ciao
> >> Hannes
> >>
> >> On 02/18/2015 05:13 AM, Nat Sakimura wrote:
> >>> Hi Hannes,
> >>>
> >>> I hereby confirm that I have submit the draft  in full conformance
> >>> with the  provisions of BCP 78 and BCP 79.
> >>>
> >>> Re: Security Consideration (7.1) and section 4.1
> >>>
> >>> The first part of the 7.1 is a non-normative prose explaining that
> >>> the implementers got to make sure that the code verifier is hard to
> >>> guessed or modeled. In a way, this is laying out the basic security
> >>> property requirment on the code verifier.
> >>>
> >>> Then, it goes onto the implementation guideance that one need to
> >>> use a cryptographic random number generator instead of relying on a
> >>> rand() in some language that are  not cryptographically random to
> >>> generate 32-octet sequence. The same text is in 4.1 as well.
> >>>
> >>> We did not copy "code verifier SHOULD have enough entropy to make
> >>> it impractical to guess the value" here because that looked
> >>> needlessly repeating, but if you want, I have no objection in
> >>> adding it to 7.1.
> >>>
> >>> Alternatively, in 7.1, after explaining the rationale, we can just
> >>> point to 4.1 for the control and implementation guidance.
> >>>
> >>> Re: 32-octet
> >>>
> >>> We chose it because we are using SHA256 in generating the code
> >>> challange. Having more entropy does not help us here, while having
> >>> less octets increases the risk.
> >>>
> >>> Best,
> >>>
> >>> Nat
> >>>
> >>>
> >>>
> >>> On Tue, 17 Feb 2015 17:56:33 +0100
> >>> Hannes Tschofenig  wrote:
> >>>
>  Hi Nat, John, Naveen,
> 
>  thanks a lot for your work on the document.
> 
>  I still need responses to this mail to complete the shepherd
>  writeup:
>  http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
> 
>  I definitely need the IPR confirmation.
> 
>  It would also be helpful to have someone who implemented the
>  specification as it currently is. I asked Brian and Thorsten for
>  clarification regarding their statements that they implemented
>  earlier versions of the spec.
> 
>  As a final remark I still believe that the text regarding the
>  randomness is still a bit inconsistent. Here are two examples:
> 
>  1) In the Security Consideration you write that "The security model
>  relies on the fact that the code verifier is not learned or
>  guessed by the attacker.  It is vitally important to adhere to
>  this principle. "
> 
>  2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
>  have enough entropy to make it impractical to guess the value.  It
>  is RECOMMENDED that the output of a suitable random number
>  generator be used to create a 32-octet sequence."
> 
>  There is clearly a long way from a SHOULD have enough entropy to
>  the text in the security consideration section where you ask for
>  32 bytes entropy.
> 
>  It is also not clear why you ask for 32 bytes of entropy in
>  particular.
> 
>  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] draft-ietf-oauth-spop-10

[Hannes Tschofenig]

I think that the "controlled environment" is a risky idea. I believe we
should definitely go for a MUST.

On 02/18/2015 10:26 AM, Nat Sakimura wrote:
> Hi Hannes, 
> 
> The reason I have put SHOULD there instead of MUST is 
> that there may be a valid reason not to in a controlled 
> environment, and it does not interfere the interoperability.
> The deployment may opt to use other control than entropy, 
> and SHOULD allows it while MUST does not. 
> 
> Having said that, if the WG is OK with a MUST there, 
> I am fine with incorporating the proposed change. 
> 
> Cheers, 
> 
> Nat
> 
> 
> On Wed, 18 Feb 2015 09:43:30 +0100
> Hannes Tschofenig  wrote:
> 
>> Hi Nat,
>>
>> thanks for the quick response.
>>
>> I was hoping to see a statement like "The code verifier MUST have
>> enough entropy to make it impractical to guess the value." in the
>> text rather than the SHOULD. Given all the other statements in the
>> draft I am not sure what the should actually means. Under what
>> conditions would an implementer not provide enough entropy to make
>> guessing impractical?
>>
>> Ciao
>> Hannes
>>
>> On 02/18/2015 05:13 AM, Nat Sakimura wrote:
>>> Hi Hannes, 
>>>
>>> I hereby confirm that I have submit the draft  in full conformance
>>> with the  provisions of BCP 78 and BCP 79.
>>>
>>> Re: Security Consideration (7.1) and section 4.1
>>>
>>> The first part of the 7.1 is a non-normative prose explaining that
>>> the implementers got to make sure that the code verifier is hard to
>>> guessed or modeled. In a way, this is laying out the basic security
>>> property requirment on the code verifier. 
>>>
>>> Then, it goes onto the implementation guideance that one need to
>>> use a cryptographic random number generator instead of relying on a
>>> rand() in some language that are  not cryptographically random to
>>> generate 32-octet sequence. The same text is in 4.1 as well. 
>>>
>>> We did not copy "code verifier SHOULD have enough entropy to make
>>> it impractical to guess the value" here because that looked
>>> needlessly repeating, but if you want, I have no objection in
>>> adding it to 7.1. 
>>>
>>> Alternatively, in 7.1, after explaining the rationale, we can just
>>> point to 4.1 for the control and implementation guidance. 
>>>
>>> Re: 32-octet
>>>
>>> We chose it because we are using SHA256 in generating the code
>>> challange. Having more entropy does not help us here, while having
>>> less octets increases the risk. 
>>>
>>> Best, 
>>>
>>> Nat 
>>>
>>>
>>>
>>> On Tue, 17 Feb 2015 17:56:33 +0100
>>> Hannes Tschofenig  wrote:
>>>
 Hi Nat, John, Naveen,

 thanks a lot for your work on the document.

 I still need responses to this mail to complete the shepherd
 writeup:
 http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html

 I definitely need the IPR confirmation.

 It would also be helpful to have someone who implemented the
 specification as it currently is. I asked Brian and Thorsten for
 clarification regarding their statements that they implemented
 earlier versions of the spec.

 As a final remark I still believe that the text regarding the
 randomness is still a bit inconsistent. Here are two examples:

 1) In the Security Consideration you write that "The security model
 relies on the fact that the code verifier is not learned or
 guessed by the attacker.  It is vitally important to adhere to
 this principle. "

 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
 have enough entropy to make it impractical to guess the value.  It
 is RECOMMENDED that the output of a suitable random number
 generator be used to create a 32-octet sequence."

 There is clearly a long way from a SHOULD have enough entropy to
 the text in the security consideration section where you ask for
 32 bytes entropy.

 It is also not clear why you ask for 32 bytes of entropy in
 particular.

 Ciao
 Hannes

>>>
>>>
>>
> 
> 



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-spop-10

[Nat Sakimura]

Hi Hannes, 

The reason I have put SHOULD there instead of MUST is 
that there may be a valid reason not to in a controlled 
environment, and it does not interfere the interoperability.
The deployment may opt to use other control than entropy, 
and SHOULD allows it while MUST does not. 

Having said that, if the WG is OK with a MUST there, 
I am fine with incorporating the proposed change. 

Cheers, 

Nat


On Wed, 18 Feb 2015 09:43:30 +0100
Hannes Tschofenig  wrote:

> Hi Nat,
> 
> thanks for the quick response.
> 
> I was hoping to see a statement like "The code verifier MUST have
> enough entropy to make it impractical to guess the value." in the
> text rather than the SHOULD. Given all the other statements in the
> draft I am not sure what the should actually means. Under what
> conditions would an implementer not provide enough entropy to make
> guessing impractical?
> 
> Ciao
> Hannes
> 
> On 02/18/2015 05:13 AM, Nat Sakimura wrote:
> > Hi Hannes, 
> > 
> > I hereby confirm that I have submit the draft  in full conformance
> > with the  provisions of BCP 78 and BCP 79.
> > 
> > Re: Security Consideration (7.1) and section 4.1
> > 
> > The first part of the 7.1 is a non-normative prose explaining that
> > the implementers got to make sure that the code verifier is hard to
> > guessed or modeled. In a way, this is laying out the basic security
> > property requirment on the code verifier. 
> > 
> > Then, it goes onto the implementation guideance that one need to
> > use a cryptographic random number generator instead of relying on a
> > rand() in some language that are  not cryptographically random to
> > generate 32-octet sequence. The same text is in 4.1 as well. 
> > 
> > We did not copy "code verifier SHOULD have enough entropy to make
> > it impractical to guess the value" here because that looked
> > needlessly repeating, but if you want, I have no objection in
> > adding it to 7.1. 
> > 
> > Alternatively, in 7.1, after explaining the rationale, we can just
> > point to 4.1 for the control and implementation guidance. 
> > 
> > Re: 32-octet
> > 
> > We chose it because we are using SHA256 in generating the code
> > challange. Having more entropy does not help us here, while having
> > less octets increases the risk. 
> > 
> > Best, 
> > 
> > Nat 
> > 
> > 
> > 
> > On Tue, 17 Feb 2015 17:56:33 +0100
> > Hannes Tschofenig  wrote:
> > 
> >> Hi Nat, John, Naveen,
> >>
> >> thanks a lot for your work on the document.
> >>
> >> I still need responses to this mail to complete the shepherd
> >> writeup:
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
> >>
> >> I definitely need the IPR confirmation.
> >>
> >> It would also be helpful to have someone who implemented the
> >> specification as it currently is. I asked Brian and Thorsten for
> >> clarification regarding their statements that they implemented
> >> earlier versions of the spec.
> >>
> >> As a final remark I still believe that the text regarding the
> >> randomness is still a bit inconsistent. Here are two examples:
> >>
> >> 1) In the Security Consideration you write that "The security model
> >> relies on the fact that the code verifier is not learned or
> >> guessed by the attacker.  It is vitally important to adhere to
> >> this principle. "
> >>
> >> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
> >> have enough entropy to make it impractical to guess the value.  It
> >> is RECOMMENDED that the output of a suitable random number
> >> generator be used to create a 32-octet sequence."
> >>
> >> There is clearly a long way from a SHOULD have enough entropy to
> >> the text in the security consideration section where you ask for
> >> 32 bytes entropy.
> >>
> >> It is also not clear why you ask for 32 bytes of entropy in
> >> particular.
> >>
> >> Ciao
> >> Hannes
> >>
> > 
> > 
> 


-- 
Nat Sakimura (n-sakim...@nri.co.jp)
Nomura Research Institute, Ltd. 

本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信
することを意図しております。意図された受取人以外の方によるこれらの情報の
開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メール
を受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受
信されたメールを削除していただきますようお願い致します。 PLEASE READ:
The information contained in this e-mail is confidential and intended
for the named recipient(s) only. If you are not an intended recipient
of this e-mail, you are hereby notified that any review, dissemination,
distribution or duplication of this message is strictly prohibited. If
you have received this message in error, please notify the sender
immediately and delete your copy from your system.

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

Re: [OAUTH-WG] draft-ietf-oauth-spop-10

[Hannes Tschofenig]

Hi John,

I am fine with the plain vs. SHA256 concept and I understand the
reasoning behind the two. Having the same for both types is also OK for me.

My question about the 32 bytes entropy was based on curiosity. SHA256 is
a function that takes an arbitrary length input and produces an output
with 256 bits. The 256bit output length does not mean that you have put
give it 256bits randomness as input.

If the group thinks that this is a reasonable value (and not too big)
then I am fine with it as well.

Ciao
Hannes

On 02/18/2015 05:42 AM, John Bradley wrote:
> We have discussed on the list making allowing the entropy for plain to be 
> smaller.
> 
> 32bytes was selected as a good value for S256.  
> 
> The reason for S256 vs plain is that you are assuming an attacker is going to 
> intercept the request, and thus you want to have enough entropy to prevent 
> offline brute force.
> 
> For plain you are assuming that the attacker can't intercept the request, and 
> if they do more entropy won't help you.
> 
> In the plain case you are only protecting against a on line guess for a 
> single use token.   That could safely be much lower entropy as it is not 
> protecting against off-line brute force.
> 128bits would be more than enough in that case.   I left it as 256bits for 
> both to not introduce more options and not confuse people about why plain 
> needs less entropy than S256.
> 
> What is the WG feeling should we recommend different minimum values for each 
> of the transforms?
> 
> John B.
> 
>> On Feb 17, 2015, at 8:56 AM, Hannes Tschofenig  
>> wrote:
>>
>> Hi Nat, John, Naveen,
>>
>> thanks a lot for your work on the document.
>>
>> I still need responses to this mail to complete the shepherd writeup:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
>>
>> I definitely need the IPR confirmation.
>>
>> It would also be helpful to have someone who implemented the
>> specification as it currently is. I asked Brian and Thorsten for
>> clarification regarding their statements that they implemented earlier
>> versions of the spec.
>>
>> As a final remark I still believe that the text regarding the randomness
>> is still a bit inconsistent. Here are two examples:
>>
>> 1) In the Security Consideration you write that "The security model
>> relies on the fact that the code verifier is not learned or guessed by
>> the attacker.  It is vitally important to adhere to this principle. "
>>
>> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD have
>> enough entropy to make it impractical to guess the value.  It is
>> RECOMMENDED that the output of a suitable random number generator be
>> used to create a 32-octet sequence."
>>
>> There is clearly a long way from a SHOULD have enough entropy to the
>> text in the security consideration section where you ask for 32 bytes
>> entropy.
>>
>> It is also not clear why you ask for 32 bytes of entropy in particular.
>>
>> Ciao
>> Hannes
>>
> 



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-spop-10

[Hannes Tschofenig]

Hi Nat,

thanks for the quick response.

I was hoping to see a statement like "The code verifier MUST have enough
entropy to make it impractical to guess the value." in the text rather
than the SHOULD. Given all the other statements in the draft I am not
sure what the should actually means. Under what conditions would an
implementer not provide enough entropy to make guessing impractical?

Ciao
Hannes

On 02/18/2015 05:13 AM, Nat Sakimura wrote:
> Hi Hannes, 
> 
> I hereby confirm that I have submit the draft  in full conformance with the  
> provisions of BCP 78 and BCP 79.
> 
> Re: Security Consideration (7.1) and section 4.1
> 
> The first part of the 7.1 is a non-normative prose explaining that the 
> implementers got to make sure that the code verifier is hard to guessed or 
> modeled. In a way, this is laying out the basic security property requirment 
> on the code verifier. 
> 
> Then, it goes onto the implementation guideance that one need to use a 
> cryptographic random number generator instead of relying on a rand() in some 
> language that are  not cryptographically random to generate 32-octet 
> sequence. The same text is in 4.1 as well. 
> 
> We did not copy "code verifier SHOULD have enough entropy to make it 
> impractical to guess the value" here because that looked needlessly 
> repeating, but if you want, I have no objection in adding it to 7.1. 
> 
> Alternatively, in 7.1, after explaining the rationale, we can just point to 
> 4.1 for the control and implementation guidance. 
> 
> Re: 32-octet
> 
> We chose it because we are using SHA256 in generating the code challange.
> Having more entropy does not help us here, while having less octets increases 
> the risk. 
> 
> Best, 
> 
> Nat 
> 
> 
> 
> On Tue, 17 Feb 2015 17:56:33 +0100
> Hannes Tschofenig  wrote:
> 
>> Hi Nat, John, Naveen,
>>
>> thanks a lot for your work on the document.
>>
>> I still need responses to this mail to complete the shepherd writeup:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
>>
>> I definitely need the IPR confirmation.
>>
>> It would also be helpful to have someone who implemented the
>> specification as it currently is. I asked Brian and Thorsten for
>> clarification regarding their statements that they implemented earlier
>> versions of the spec.
>>
>> As a final remark I still believe that the text regarding the
>> randomness is still a bit inconsistent. Here are two examples:
>>
>> 1) In the Security Consideration you write that "The security model
>> relies on the fact that the code verifier is not learned or guessed by
>> the attacker.  It is vitally important to adhere to this principle. "
>>
>> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
>> have enough entropy to make it impractical to guess the value.  It is
>> RECOMMENDED that the output of a suitable random number generator be
>> used to create a 32-octet sequence."
>>
>> There is clearly a long way from a SHOULD have enough entropy to the
>> text in the security consideration section where you ask for 32 bytes
>> entropy.
>>
>> It is also not clear why you ask for 32 bytes of entropy in
>> particular.
>>
>> Ciao
>> Hannes
>>
> 
> 



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth