Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AE21B315D for ; Wed, 25 Nov 2015 14:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRWKG546Gdh9 for ; Wed, 25 Nov 2015 14:12:53 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9A611B315C for ; Wed, 25 Nov 2015 14:12:52 -0800 (PST) Received: by wmec201 with SMTP id c201so88220590wme.1 for ; Wed, 25 Nov 2015 14:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=W2yL93v8VCUBFRnJICG7fxOVE/SgPDphcjt2qF9wiIE=; b=vjZcmkqCqR+VlMo80P2zy/JAAoDNYxMeni0yBJdukaNrLjhW3oe3KCqQhEFkKog31w GMEKFxZ7nsBi/ld961OCvf8+LlwvedSxgn2gboxBwSIZ70rZYBQpuzZxMgBbe3YOoXHt p559XZJwA/V0Yx0OBUzPOTiKKhnLB7A8rDNthOva0I4DoYywo2lR16lb66NKgIDeMmcx coG1jmxW/KRwLxJHG3bYWW8cszEHlDeatR20wA8a+iT75C3sOGzbem2D0X0QxqNWsydn hdH4innkblVhEzWTl7C34C9Q0u4FNO4QoiyNr9OtHyj14aVyUXqzHRSw9DsQbGCW29p9 kBvg== MIME-Version: 1.0 X-Received: by 10.194.179.71 with SMTP id de7mr44794493wjc.119.1448489570846; Wed, 25 Nov 2015 14:12:50 -0800 (PST) Received: by 10.28.52.130 with HTTP; Wed, 25 Nov 2015 14:12:50 -0800 (PST) In-Reply-To: <4AF8FE9C-3484-410B-B52F-C1F9706B18A5@ve7jtb.com> References: <4AF8FE9C-3484-410B-B52F-C1F9706B18A5@ve7jtb.com> Date: Wed, 25 Nov 2015 17:12:50 -0500 Message-ID: From: Kathleen Moriarty To: John Bradley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 22:12:55 -0000 Thanks, John! On Wed, Nov 25, 2015 at 4:41 PM, John Bradley wrote: > I prefer the new wording. > > However the last part could be clearer. >> use be implemented by recipients. > > Or perhaps the blunter =E2=80=9CRecipients only understanding bearer toke= ns may accept JWT containing =E2=80=9Ccnf=E2=80=9D elements if all the othe= r required claims are valid. It is important for security to audience rest= rict tokens using the JWT =E2=80=9Caud claim. The =E2=80=9Ccnf=E2=80=9D cl= aim MUST NOT be used as a pseudo audience restriction.=E2=80=9D More explicit text like this is is more helpful in my opinion. Kathleen > > Looking at the comments, I get the feeling that some people might think t= hat cnf may restrict what endpoints can receive the token (because of the k= ey distribution) it only allows endpoints that should receive the token to= reject ones that come from entities who don=E2=80=99t possess the correct = confirmation. > > John B. > >> On Nov 25, 2015, at 12:25 AM, Mike Jones w= rote: >> >> Rather than elaborating, having looked at the text we're discussing agai= n, 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 fo= r you to simplify the current text: >> >> "A recipient might not understand the cnf claim, in which case it wil= l typically be ignored. Unless this is acceptable behavior, applications th= at need the proof-of-possession keys communicated with it to be understood = and processed must require that the parts of this specification that they u= se be implemented." >> >> to this simpler text? >> >> "A recipient might not understand the cnf claim. Applications that n= eed the proof-of-possession keys communicated with it to be understood and = processed must require that the parts of this specification that they use b= e implemented." >> >> 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 hav= e to be re-raised here, as it currently is. Re-raising it is clearly a poi= nt of distraction. >> >> For what it's worth, I don't remember any DISCUSSes on this topic (altho= ugh it's possible that your memory is better than mine on this point). >> >> Best wishes, >> -- Mike >> >> -----Original Message----- >> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] >> Sent: Tuesday, November 24, 2015 7:14 PM >> To: Mike Jones >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possessio= n >> >> On Tue, Nov 24, 2015 at 10:10 PM, Mike Jones wrote: >>> Fair question about the use of "typically". The reason it's there is t= hat this language in JWT [RFC 7519] Section 4 does permit applications to r= equire that JWTs with not-understood claims be rejected, rather than ignore= d, even though that's not the default behavior: >>> >>> 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. >>> >>> So when not understood, "cnf" would typically be ignored, but might not= be. >> >> I find that confusing and am now thinking this came up in a discuss as w= ell during the review for 7519, didn't it? Can you elaborate int eh securi= ty considerations section a bit more, otherwise this text appears to be con= flicting and even with what you intend, it's confusing for implementers and= will lead to issues with interoperability. >> >> Thanks, >> Kathleen >> >> >>> >>> -- Mike >>> >>> -----Original Message----- >>> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] >>> Sent: Tuesday, November 24, 2015 6:41 PM >>> To: Mike Jones >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] AD review of >>> draft-ietf-oauth-proof-of-possession >>> >>> Hi Mike, >>> >>> Thanks for the quick turn-around. Just one more comment on my comments= . >>> >>> On Tue, Nov 24, 2015 at 9:10 PM, Mike Jones wrote: >>>> Thanks for your review comments, Kathleen. Responses are inline below= ... >>>> >>>>> -----Original Message----- >>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kathleen >>>>> 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 >>>>> >>>>> Hi, >>>>> >>>>> Thank you all for your work on this draft! I just have a few questio= ns: >>>>> >>>>> 1. Security considerations section says: >>>>> >>>>> "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." >>>>> >>>>> I find that to be odd phrasing that would likely be picked up in >>>>> subsequent reviews. Please remove the word "normal" so that all of >>>>> the security issues discusses in JWT are included. Are there other >>>>> 'normal considerations in addition to those in JWT that need to be >>>>> listed? The phrasing reads as if that may the case and would be >>>>> better to include them all or pointers or change the phrasing. >>>> >>>> You're right. I removed this awkward wording. >>>> >>>>> 2. Also in the security considerations section, >>>>> >>>>> "A recipient may not understand the newly introduced "cnf" claim an= d >>>>> may consequently treat it as a bearer token." >>>>> >>>>> What is the proper handling requirement when an unknown claim is >>>>> 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." >>>>> >>>>> Is this why it is treated as a bearer token rather than being >>>>> rejected? Is this really the action you want to see with cnf? Why >>>>> isn't there an error and a resend as a bearer token so that parties >>>>> understand (or have an opportunity to understand) that there were iss= ues? >>>>> >>>>> 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 >>>>> details, >>>>> >>>>> How is this outside of the scope of this draft? cnf is defined in >>>>> this draft, so handling should be covered in this draft. A pointer >>>>> to the POP architecture draft is not helpful as it is not defined >>>>> there, it's covered int his draft. Should this text just be removed >>>>> and replaced with more explicit handling information int he body of t= his draft? >>>> >>>> Good catch. JWT [RFC 7519] Section 4 says that claims that are not un= derstood must be ignored unless otherwise specified by the application. Th= is allows new claims to be dynamically added without breaking existing appl= ications. For the same reason, I have incorporated this language about und= erstanding claims from 7519, but having it be about understanding confirmat= ion members. Ultimately, what features must be implemented are always up t= o the application, just as with JWT claims. >>> >>> The new text in Section 3.1 looks good. I'm not sure why the word "typ= ically" appears int he new text of the security considerations section thou= gh after reading the new text in 3.1. Wouldn't it just be ignored since 3.= 1 now says: >>> >>> "However, in the absence of such requirements, >>> all confirmation members that are not understood by implementations >>> MUST be ignored." >>> >>> Thanks, >>> Kathleen >>> >>> >>>> >>>>> Thanks! >>>>> >>>>> -- >>>>> >>>>> Best regards, >>>>> Kathleen >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> Thanks again, >>>> -- Mike >>>> >>> >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >> >> >> >> -- >> >> Best regards, >> Kathleen >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > --=20 Best regards, Kathleen