Subject: [OAUTH-WG] draft-ietf-oauth-spop-10: Your feedback needed.

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 02 Mar 2015 16:31:20 +0100

Hi all,

I am trying to finalize my work on the shepherd write-up of
draft-ietf-oauth-spop.

Unfortunately, there are still some outstanding issues:

1. S256 as a mandatory-to-implement code challenge method
(by the Authorization Server)

Currently, S256 is MTI but implementations do not use S256 (yet).
Hence, we have very few (maybe not even a single) implementation
that is in conformance with the specification at the moment.

Does the group see a problem with this choice of MTI
(or lack of conformance)?

2. Naveen Agarwal has not provided his confirmation that any and
all appropriate IPR disclosures required for full conformance
with the provisions of BCP 78 and BCP 79 have already been filed.

Without his confirmation I cannot finalize my shepherd write-up.

3. Normative language regarding code verifier randomness

We had a discussion about the language used to describe what
implementations need to provide in terms of randomness of the
code verifier. Here is the discussion thread:
http://www.ietf.org/mail-archive/web/oauth/current/msg14217.html

Ultimately, the issue boiled down to the following sentence and
the use of 'MUST' vs. 'SHOULD':

"the code verifier SHOULD have enough entropy to make it
impractical to guess the value"

It would be good to know whether the group objects using MUST
instead of SHOULD to enhance security.

Ciao
Hannes

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 02 Mar 2015 19:21:49 +0100

Hi Hannes,

> (or lack of conformance)?

As already indicated on the list: The original reason to invent spop was 
to prevent malicous apps, which intercepted the redirect back to the 
legitimate app and that way impersonated the user (see section 1). In my 
opinion, "plain" fullfils this goal. I therefore don't see a need (or 
justification) to make S256 MTI.

The security considerations sections says:

"If the "plain" method is used,
    there is a chance that it will be observed by the attacker on the
    device."

Under which circumstances is an attacker supposed to observe the 
challenge on the device? And if the attacker is able to observe the URLs 
in an embedded or the system browser, isn't this attacker most likely 
capable of observing password input in the same browser? In this case, 
we should rather be concerned regarding the user's password then 
anything else.

kind regards,
Torsten.

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth