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

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Feb 2015 17:48:57 +0100

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
> <[email-masked] <mailto:[email-masked]>>:
> 
>>
>> On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig
>> <[email-masked] <mailto:[email-masked]>> 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
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Feb 2015 17:49:55 +0100

Hi Brian,

what is different between the version you guys implemented and the
version that is currently documented in the latest version of the draft?

Ciao
Hannes

On 01/30/2015 06:50 PM, Brian Campbell wrote:
> We have an AS side implementation of an earlier draft that was released
> in June of last year:

---

From: Brian Campbell <[email-masked]>
Date: Tue, 17 Feb 2015 15:17:00 -0700

When we did the implementation there was no S256 transformation defined or
made MTI for the server. I'm pretty sure it was http://tools.ietf.org/html/
draft-sakimura-oauth-tcse-03

Thus, our server supports only the "no transformation" (as it was called
then) or the "plain" code_challenge_method (as it's called now).

It is compatible with the latest version of the draft for a client using
the "plain" code_challenge_method (thank you to everyone for maintaining
that). But wouldn't work for the "S256" code_challenge_method as it didn't
exist at the time we implemented.

---

From: [email-masked]
Date: Wed, 18 Feb 2015 14:16:02 +0100

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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Feb 2015 16:33:01 +0100

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

---

From: Brian Campbell <[email-masked]>
Date: Wed, 18 Feb 2015 09:45:53 -0700

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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Feb 2015 18:33:17 +0100

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:
> On Wed, Feb 18, 2015 at 8:33 AM, Hannes Tschofenig
>     On 02/18/2015 02:16 PM, [email-masked]
>     <mailto:[email-masked]> wrote:
>     > Hi Hannes,
>     >
>     >>> <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>>:
>     >>>
>     >>>>
>     >>>> <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>     >>>>
>     >>>>
>     >>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 18 Feb 2015 21:15:52 +0100

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 <[email-masked]>:
>>     > deviation, we do not enforce the minimum length of 43
>characters
>>     of the
>>     > code verifier.
>>     >
>>     > kind regards,
>>     > Torsten.
>>     >
>>     >>> Deutsche Telekom also implemented an early version of the
>draft last
>>     >>> year.
>>     >>>
>>     >>>
>>     >>>
><mailto:[email-masked]

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

---

From: John Bradley <[email-masked]>
Date: Wed, 18 Feb 2015 12:28:21 -0800

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 <[email-masked]> wrote:
> 
>>>  <[email-masked]
>>> <mailto:[email-masked]>> wrote:
>>>  
>>>>  deviation, we do not enforce the
>>>> minimum length of 43 characters
>>>      of the
>>>>  code verifier.
>>>> 
>>>>  kind regards,
>>>>  Torsten.
>>>> 
> [email-masked]

---

From: Brian Campbell <[email-masked]>
Date: Thu, 19 Feb 2015 15:27:46 -0700

I can't comment with any authority on product road-map (that's above my
pay-grade) but I can speculate that we probably would support "S256"
eventually.

On Wed, Feb 18, 2015 at 10:33 AM, Hannes Tschofenig <
[email-masked]> wrote:

> >     >>> Deutsche Telekom also implemented an early version of the draft
> last
> >     >>> year.
> >     >>>
> >     >>>
> >     >>>