From: Mike Jones <Michael.Jones@microsoft.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Thread-Topic: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession
Thread-Index: AQHRJt++kWDp0FqlfEmPEzc+Ih7voJ6r6UxQgAAee4CAAAb2QIAAAjcAgAAA9fCAALluAIAJxh2g
Date: Tue, 1 Dec 2015 19:39:13 +0000
Message-ID: <BY2PR03MB442E21DE2BA8CC5D29E5B4AF50F0@BY2PR03MB442.namprd03.prod.outlook.com>
References: <CAHbuEH4J5SYVuWe5+OHfCQARuZhOJ6hG=5RqUkh5Ebad_RneAg@mail.gmail.com>
 <BY2PR03MB442BD8E7C5AFA8D79C79AEAF5050@BY2PR03MB442.namprd03.prod.outlook.com>
 <CAHbuEH7pJFKH_gJE6aSHCBQZL5eZ9qxyHajzjwz=5v8+LD7ywQ@mail.gmail.com>
 <BY2PR03MB4422F5F3905D4118D9D540BF5050@BY2PR03MB442.namprd03.prod.outlook.com>
 <CAHbuEH6x4fxPmho8RbgFLngXGROcDfGhSWkDAAciVkYa7AOXTw@mail.gmail.com>
 <BY2PR03MB44297DA1D6A4C4F125EBCFCF5050@BY2PR03MB442.namprd03.prod.outlook.com>
 <F4372014-9338-4EEA-B49A-CA53E73BC6A0@gmail.com>
In-Reply-To: <F4372014-9338-4EEA-B49A-CA53E73BC6A0@gmail.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: microsoft.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2015 19:39:13.2571 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/03pb_4RLwNAWGTnd7uSXZG9hAzU>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>,
 <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>,
 <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Dec 2015 19:39:38 -0000

Hi Kathleen,

As you saw, I posted draft -08 yesterday with the additional security consi=
derations John, you, and I had discussed.  I wanted to check in with you an=
d see if that addresses the point you were going to make in your ballot or =
whether there is more you'd like us to do before the IETF review.

				Best wishes,
				-- Mike

-----Original Message-----
From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]=20
Sent: Wednesday, November 25, 2015 6:21 AM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession

Hi Mike,

If the working group is okay with the current text, leave it.  What you pro=
posed is exactly the same as what is there.  I'll note this point in my bal=
lot as I think you are leaving ambiguity that is not necessary.

After getting far enough on this, I think it was Pete who discussed this wi=
th you and he gave up and remained in disagreement.

Regards,
Kathleen=20

Sent from my iPhone

> On Nov 24, 2015, at 10:25 PM, Mike Jones <Michael.Jones@microsoft.com> wr=
ote:
>=20
> Rather than elaborating, having looked at the text we're discussing again=
, I'm going to counter-propose that we instead simplify - sticking only to =
the point that the paragraph is intending to get across.  Would it work for=
 you to simplify the current text:
>=20
>    "A recipient might not understand the cnf claim, in which case it will=
 typically be ignored. Unless this is acceptable behavior, applications tha=
t need the proof-of-possession keys communicated with it to be understood a=
nd processed must require that the parts of this specification that they us=
e be implemented."
>=20
> to this simpler text?
>=20
>    "A recipient might not understand the cnf claim.  Applications that ne=
ed the proof-of-possession keys communicated with it to be understood and p=
rocessed must require that the parts of this specification that they use be=
 implemented."
>=20
> The "must ignore" topic is already addressed in the second paragraph of 3=
.1 (and with exactly the semantics as the rest of JWT), and so doesn't have=
 to be re-raised here, as it currently is.  Re-raising it is clearly a poin=
t of distraction.
>=20
> For what it's worth, I don't remember any DISCUSSes on this topic (althou=
gh it's possible that your memory is better than mine on this point).
>=20
>                Best wishes,
>                -- Mike
>=20
> -----Original Message-----
> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]
> Sent: Tuesday, November 24, 2015 7:14 PM
> To: Mike Jones <Michael.Jones@microsoft.com>
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] AD review of=20
> draft-ietf-oauth-proof-of-possession
>=20
>> On Tue, Nov 24, 2015 at 10:10 PM, Mike Jones <Michael.Jones@microsoft.co=
m> wrote:
>> Fair question about the use of "typically".  The reason it's there is th=
at this language in JWT [RFC 7519] Section 4 does permit applications to re=
quire that JWTs with not-understood claims be rejected, rather than ignored=
, even though that's not the default behavior:
>>=20
>>   The set of claims that a JWT must contain to be considered valid is
>>   context dependent and is outside the scope of this specification.
>>   Specific applications of JWTs will require implementations to
>>   understand and process some claims in particular ways.  However, in
>>   the absence of such requirements, all claims that are not understood
>>   by implementations MUST be ignored.
>>=20
>> So when not understood, "cnf" would typically be ignored, but might not =
be.
>=20
> I find that confusing and am now thinking this came up in a discuss as we=
ll during the review for 7519, didn't it?  Can you elaborate int eh securit=
y considerations section a bit more, otherwise this text appears to be conf=
licting and even with what you intend, it's confusing for implementers and =
will lead to issues with interoperability.
>=20
> Thanks,
> Kathleen
>=20
>=20
>>=20
>>                                -- Mike
>>=20
>> -----Original Message-----
>> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]
>> Sent: Tuesday, November 24, 2015 6:41 PM
>> To: Mike Jones <Michael.Jones@microsoft.com>
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] AD review of=20
>> draft-ietf-oauth-proof-of-possession
>>=20
>> Hi Mike,
>>=20
>> Thanks for the quick turn-around.  Just one more comment on my comments.
>>=20
>>> On Tue, Nov 24, 2015 at 9:10 PM, Mike Jones <Michael.Jones@microsoft.co=
m> wrote:
>>> Thanks for your review comments, Kathleen.  Responses are inline below.=
..
>>>=20
>>>> -----Original Message-----
>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen=20
>>>> Moriarty
>>>> Sent: Tuesday, November 24, 2015 9:44 AM
>>>> To: oauth@ietf.org
>>>> Subject: [OAUTH-WG] AD review of
>>>> draft-ietf-oauth-proof-of-possession
>>>>=20
>>>> Hi,
>>>>=20
>>>> Thank you all for your work on this draft!  I just have a few question=
s:
>>>>=20
>>>> 1. Security considerations section says:
>>>>=20
>>>> "All of the normal security issues, especially in relationship to
>>>>   comparing URIs and dealing with unrecognized values, that are
>>>>   discussed in JWT [JWT] also apply here."
>>>>=20
>>>> I find that to be odd phrasing that would likely be picked up in=20
>>>> subsequent reviews.  Please remove the word "normal" so that all of=20
>>>> the security issues discusses in JWT are included.  Are there other=20
>>>> 'normal considerations in addition to those in JWT that need to be=20
>>>> listed?  The phrasing reads as if that may the case and would be=20
>>>> better to include them all or pointers or change the phrasing.
>>>=20
>>> You're right.  I removed this awkward wording.
>>>=20
>>>> 2. Also in the security considerations section,
>>>>=20
>>>>   "A recipient may not understand the newly introduced "cnf" claim and
>>>>   may consequently treat it as a bearer token."
>>>>=20
>>>> What is the proper handling requirement when an unknown claim is=20
>>>> present?  Section 3.1 says:
>>>>  "When a recipient receives a "cnf" claim with a
>>>>   member that it does not understand, it MUST ignore that member."
>>>>=20
>>>> Is this why it is treated as a bearer token rather than being=20
>>>> rejected?  Is this really the action you want to see with cnf?  Why=20
>>>> isn't there an error and a resend as a bearer token so that parties=20
>>>> understand (or have an opportunity to understand) that there were issu=
es?
>>>>=20
>>>> Then the following text in the security section says:
>>>>  "While this is a
>>>>   legitimate concern, it is outside the scope of this specification,
>>>>   since demonstration the possession of the key associated with the
>>>>   "cnf" claim is not covered by this specification. For more=20
>>>> details,
>>>>=20
>>>> How is this outside of the scope of this draft?  cnf is defined in=20
>>>> this draft, so handling should be covered in this draft.  A pointer=20
>>>> to the POP architecture draft is not helpful as it is not defined=20
>>>> there, it's covered int his draft.  Should this text just be=20
>>>> removed and replaced with more explicit handling information int he bo=
dy of this draft?
>>>=20
>>> Good catch.  JWT [RFC 7519] Section 4 says that claims that are not und=
erstood must be ignored unless otherwise specified by the application.  Thi=
s allows new claims to be dynamically added without breaking existing appli=
cations.  For the same reason, I have incorporated this language about unde=
rstanding claims from 7519, but having it be about understanding confirmati=
on members.  Ultimately, what features must be implemented are always up to=
 the application, just as with JWT claims.
>>=20
>> The new text in Section 3.1 looks good.  I'm not sure why the word "typi=
cally" appears int he new text of the security considerations section thoug=
h after reading the new text in 3.1.  Wouldn't it just be ignored since 3.1=
 now says:
>>=20
>>   "However, in the absence of such requirements,
>>    all confirmation members that are not understood by implementations
>>    MUST be ignored."
>>=20
>> Thanks,
>> Kathleen
>>=20
>>=20
>>>=20
>>>> Thanks!
>>>>=20
>>>> --
>>>>=20
>>>> Best regards,
>>>> Kathleen
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>>                                Thanks again,
>>>                                -- Mike
>>=20
>>=20
>>=20
>> --
>>=20
>> Best regards,
>> Kathleen
>=20
>=20
>=20
> --
>=20
> Best regards,
> Kathleen