From nobody Fri Aug 4 14:41:44 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FA9127058; Fri, 4 Aug 2017 14:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com 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 aoBjwSuCTpRA; Fri, 4 Aug 2017 14:41:33 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9905A12711E; Fri, 4 Aug 2017 14:41:30 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1501882866; h=from:subject:to:date:message-id; bh=Zl02FV9+6l9ARtAEGiztoDZNr1RI+dIYbFlxWimqcGo=; b=TPEoxXOMi/Rs5CqkbeTGCukZxKNH5iTzPc5o1K3Cv59PbjeDLlsv946tzI+J8Jd5rSgxEfIyr5a lRM08s5tfokyIS4tYBmTaZxwyfJjWAXRBDy/8HCJe9hxxcon9mqs18xsrqlHxQUPcsv9lazAGRb3q y+u4FdFFB/7BM9nnpu+t2/O0kOvWcm1UYU/Mm+WPH566AH64/eG30KqUYjbLy0BKSqTXZc2+ahd7i mEmx/TJPceFPPu/pBaS5V4n11moCexpUgwyhAshBNzOyjNt/UfcKNAB/lk9LrgOl+TFGFWdLOY1I6 54aukfZwdfZ8KfwQI5d0ZlYMo8VGU2j2yI7A== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 4 Aug 2017 14:41:05 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 4 Aug 2017 14:41:02 -0700 From: Jim Schaad To: CC: Date: Fri, 4 Aug 2017 14:41:22 -0700 Message-ID: <03aa01d30d6a$6c336b80$449a4280$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdMNaZmFgsJjI4oYRjeiueXD9GUQ1g== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Review of draft-ietf-ace-oauth-authz-06 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 21:41:37 -0000 As promised I finally got finished with this review. 1. Need to decide if /token, /introspect and /authz-info are under /.well-defined or not. If they are then this needs to be noted and there needs to be an IANA action if this has not already been done for OAuth. 2. Add some of the actor terms to section 2- such as Resource Owner 3. Still unhappy about the lack of POP between C and AS. How does the AS know that the key it is binding to the token is the right one. The RS has no problems, but assumes that the AS did its job. 4. If I want to use the SCOPES field as defined by Carsten, then I do not want the current restriction that is being imposed on the scope parameter in Section 3 (?) Under "Scopes and Permissions". 5. In section 3.2 - s/so- called// - don't be pejorative. 6. In section 4 - 2nd paragraph before figure 1 - I want the ACE profile to provide one method to do this. There may be others that are specific to the profile however. 7. In section 4 - Under "ACE Profiles" - RECOMMENDS seems to be an odd thing to have here - this is not really a protocol recommendation is it? Are we allowing for JSON to be used rather than CBOR? The text here on what encodings to use could be made more declarative. Are we expecting any JSON use at this point for any profile define? If so then a list of tradeoffs for profile creators and how to detect would be in order rather than the big RECOMMENDS. 8. Section 5.1 - Awkward language "If the client should to act" 9. Section 5.3 - Is this really what you want to say is that one SHOULD authenticate C to the AS? I think this is a MUST. I question if this is really something that profiles should do rather than this document. I thought that the profiles were targeted at the C <-> RS conversation. 10. Section 5.4 appears to create a new endpoint that has not been discussed in other contexts. Is this intentional? 11. Section 5.5.1 - OK - I am reversing thinking. However I need to get a summary of what a profile is going to need to specify a long ways before I get to this point. Perhaps has part of the overview. One of the questions is going to be can the C-AS section of one profile be used with the C-RS of another profile and keep the same security guarantees. The overview is going to need to talk about this at some point. 12. Section 5.5.1 - I would like to add some additional parameters at this point. The first is a RS_Data field which is copied from the RS->C message verbatim. It allows for encrypted data to be passed from the RS to the AS as part of the request. Data type is COSE_Encrypt. 13. Section 5.5.1 - I would like to see an AS field documented here so th that the 4 corner model can work. 14. Section 5.5.1 - What is the default - use this for "aud"? How is a client supposed to know what to put here for a new RS? 15. Section 5.5.1 - on cnf - Use "It is RECOMMENDED that an AS reject a request with a symmetric key" as this is positive and where enforcement is done. 16. Figure 3 - This example no longer looks correct. the content type should be the same as for Figure 2. That is assuming it is really CoAP and not HTTP? 17. Figure 4 - need to check out if client_secret is a real secret or not - it seems odd to say don't use symmetric and then have an example of passing one. Could be something else as I don't have RFC 6749 w/ me. 18. The set of operations should start with the C->RS response structure from DTLS profile as this is really the first thing that happens. 19. Is there a reason for a client not being able to request a profile rather than having it be configured into the AS? 20. Section 5.5.2 - You are not being constant about encoding - this is saying MUST be CBOR while earlier it was only a recommendation, 21. Section 5.5.2 - Post figure 5 it says examples - but only one example exists. 22. Section 5.5.4.2 - Please make the abbreviations mandatory not optional. I don't really want to support both. 23. Section 5.5.4.4 - Please define profile as being part of a CWT so that it can be communicated to the RS in the event that more than one profile is supported. Optional if RS only does one. 24. Section 5.5.4.5 - I don't know if it would not be cleaner to have a cnf that is only for the client key info and an rs_cnf (defined for introspection) that is for dealing with the RS keys. That makes it cleaner when looking a the case of an AS->C or an AS->R->C message as the fields will be the same. 25. Section 5.5.4.5 - Figure 9 does not really make sense by itself. It needs to have some context because it looks the same as for a RS key. 26. Section 5.5.4.5 - Figure 10 is not formatted correctly as the map wrapping is missing on unprotected. Look @ section 3.3. RFC 6749 about scopes 27. Need to know how to think about the idea of a client doing an introspection. Is the response going to be different than a RS doing the query? I assume that the distinction would be based on the authentication and internal knowledge - does not need to be documented except for response differences. 28. Figure 14 needs to be updated 29. Section 5.6.2 - Need to add rs_cnf - if more than one key need to tell the RS what key to use. 30. Section 5.6.4 - I think this is a required item if introspection is going to be able to return a random symmetric key. Not needed otherwise. 31. Section 5.6.4 - last para - may want to state that this secret is established at the same time that the token is established. 32. Section 5.6.4 - establish MTI algorithms here? 33. Section 5.7 - I think that you need to add rs_cnf in the event of an RS w/ multiple keys so it knows which to use. usage would be optional. 34. Section 5.7 - last paragraph - should be JOSE and COSE not JSON and CBOR. 35. Section 5.7.1 - Why would the RS respond with the cti - given a lack of text it is not clear when the MAY would be triggered. 36. Section 5.7.1 - Not sure how much information is being leaked by having different error codes being returned in these situations. May only want to have one code. 37. Section 5.7.1 - under what circumstances is the introspection request not made? If the introspection request is done async how is the client token communicated back to the client? Would that be done as part of a later access. Seems to be dicey. 38. Random thought - Is there a requirement that the same method be used for both posting to /authz-info and to the resource? Could one use OSCOAP for one and DTLS for the other? Question is because we are profiling and the assumption is that profiles are whole. 39. Section 5.7.2 - Last bullet - should note that tokens need to be shared to the RS - AS may issue lots of tokens but if RS gets none then no expirations 40. Section 5.7.2 - Another "long running request" might be the case of sending back an ACK for a request followed by a 4.01 because the token expires before the request has finished processing. Re-doing introspection might also cause this sequence of messages 41. Section 6 - personal preference - remove the first sentence it is not useful. 42. Section 6 - Protection is from signature or MAC - but we are using AEAD for most of these. Should probably have a security consideration that AEAD is preferred to MAC in most cases because of confidentiality as well. 43. Section 6- the phrase 'long-term key shared with RS' implies to me that this is a symmetric key. May want different language to allow for people thinking of asymmetric keys as well. 44. Section 6 - Please explain to me how targeting multiple RS with an asymmetric key is a problem - change it form shared secret to symmetric key. 45. Section 6- I think you want to use a different term than token replay in this paragraph. If a RS is rebooted and loses all token information, there is nothing wrong with a C doing a replay of the token to the RS to get access to the resources as long as it is still valid. 46. Section 6 - Is the confidentiality protection a requirement for asymmetric keys as well? -- Oh - and it may not be a session key, the session key for DTLS is established later, it is just a POP value (or key if asymmetric) 47. Section 6 - Sentence structure of this paragraph is difficult. The AS does not use shorter key sizes, it will perhaps create shorter POP keys. However, even this may be a problem depending on how short they are. A tradeoff is going to occur here with the ability to record and later decrypt keys depending how short the keys are. 47. Section 6 - the next to last paragraph is a repeat - but probably clearer. 48. Section 6 - Please explain the reasoning behind the last paragraph. It does not make a great deal of sense to me. 49. Section 7 - I don't understand what you are trying to say with the last sentence in the second paragraph. Given that the AS still needs to do ACL control, this does not make sense to me. For now I skipped IANA considerations and the appendixes. Let me know if you would prefer that I place these items into the issue list on github or if you prefer doing it. Jim From nobody Mon Aug 7 02:16:49 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6DA132193; Mon, 7 Aug 2017 02:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 pZI60U9_J6wu; Mon, 7 Aug 2017 02:16:44 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925D813218F; Mon, 7 Aug 2017 02:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v779GBEW014390; Mon, 7 Aug 2017 11:16:11 +0200 (CEST) Received: from aung.tzi.org (unknown [IPv6:2001:638:708:301:224:d6ff:fe13:2040]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xQsMv3zvGzDMPG; Mon, 7 Aug 2017 11:16:11 +0200 (CEST) From: Olaf Bergmann To: Jim Schaad Cc: , ace@ietf.org References: <03aa01d30d6a$6c336b80$449a4280$@augustcellars.com> Date: Mon, 07 Aug 2017 11:16:11 +0200 In-Reply-To: <03aa01d30d6a$6c336b80$449a4280$@augustcellars.com> (Jim Schaad's message of "Fri, 4 Aug 2017 14:41:22 -0700") Message-ID: <87shh3oi04.fsf@aung.informatik.uni-bremen.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-oauth-authz-06 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 09:16:47 -0000 Jim Schaad writes: > As promised I finally got finished with this review. > > 1. Need to decide if /token, /introspect and /authz-info are under > /.well-defined or not. If they are then this needs to be noted and there > needs to be an IANA action if this has not already been done for OAuth. Another option would be more flexible: You could have a well-defined (and IANA-registered) resource type that allows linking to the token- introspect and authz-info endpoints. In the /.well-known/core of as.example.com, you would find ;rt=3D"auth-request" or, in a resource directory, you could link to as.example.com's token endpoint as follows: ;rt=3D"auth-request";anchor=3D"coaps://as.example.com/" Gr=C3=BC=C3=9Fe Olaf From nobody Mon Aug 7 06:04:07 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E10112EC11 for ; Mon, 7 Aug 2017 06:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 kNwM3yy_VgsD for ; Mon, 7 Aug 2017 06:04:02 -0700 (PDT) Received: from se-out1.mx-wecloud.net (se-out1.mx-wecloud.net [89.221.255.93]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A01E132043 for ; Mon, 7 Aug 2017 06:04:02 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out1.mx-wecloud.net (Postfix) with ESMTPS id DE9D6201810 for ; Mon, 7 Aug 2017 13:03:58 +0000 (UTC) Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Mon, 7 Aug 2017 15:04:05 +0200 From: Ludwig Seitz To: References: <03aa01d30d6a$6c336b80$449a4280$@augustcellars.com> Message-ID: <440e7514-da45-1633-5ec9-1134d6a1c079@ri.se> Date: Mon, 7 Aug 2017 15:03:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <03aa01d30d6a$6c336b80$449a4280$@augustcellars.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=aq3CMWRV c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=IkcTkHD0fZMA:10 a=KeKAF7QvOSUA:10 a=NEAV23lmAAAA:8 a=bvl5n2VukKcZDayJo5sA:9 a=QEXdDO2ut3YA:10 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-oauth-authz-06 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 13:04:06 -0000 On 2017-08-04 23:41, Jim Schaad wrote: > As promised I finally got finished with this review. Thank you for your very thorough review Jim. Comments inline (note that there are a few questions as well). /Ludwig > > 1. Need to decide if /token, /introspect and /authz-info are under > /.well-defined or not. If they are then this needs to be noted and there > needs to be an IANA action if this has not already been done for OAuth. I've added an issue to our issue tracker on this. However I would think that this is something that would need to apply to OAuth as well. > > 2. Add some of the actor terms to section 2- such as Resource Owner Ok, will do > > 3. Still unhappy about the lack of POP between C and AS. How does the AS > know that the key it is binding to the token is the right one. The RS has > no problems, but assumes that the AS did its job. I'm not sure what problem that would solve. That C binds the token to a key it doesn't own? What benefit would C have from that? If C wants to relay a token to a "friend" it could always share the pop-key with said friend. > > 4. If I want to use the SCOPES field as defined by Carsten, then I do not > want the current restriction that is being imposed on the scope parameter in > Section 3 (?) Under "Scopes and Permissions". I'm just reiterating the definition of the scope parameter from the OAuth spec. I think Carsten's approach can be modified to fit into that spec. > > 5. In section 3.2 - s/so- called// - don't be pejorative. Ok, I'll rephrase that > > 6. In section 4 - 2nd paragraph before figure 1 - I want the ACE profile to > provide one method to do this. There may be others that are specific to the > profile however. I've already made that change in the "insertDiscovery" branch (https://github.com/LudwigSeitz/ace-oauth/tree/insertDiscovery). > > 7. In section 4 - Under "ACE Profiles" - RECOMMENDS seems to be an odd > thing to have here - this is not really a protocol recommendation is it? > Are we allowing for JSON to be used rather than CBOR? The text here on what > encodings to use could be made more declarative. Are we expecting any JSON > use at this point for any profile define? If so then a list of tradeoffs > for profile creators and how to detect would be in order rather than the big > RECOMMENDS. You mean section 5 right? Yes the intention is to allow profiles to specify JSON (or something else) as data format instead of CBOR. > > 8. Section 5.1 - Awkward language "If the client should to act" Yeah that whole section needed a review. Fixed. > > 9. Section 5.3 - Is this really what you want to say is that one SHOULD > authenticate C to the AS? I think this is a MUST. I question if this is > really something that profiles should do rather than this document. I > thought that the profiles were targeted at the C <-> RS conversation. My intention for the profiles is that they specify the communication (and communication security protocols). This MUST cover C <-> RS and MAY include AS <-> *any*. I agree there should be a default fallback for the MAY parts. Adding issue. > 10. Section 5.4 appears to create a new endpoint that has not been > discussed in other contexts. Is this intentional? No that's just an existing OAuth endpoint. Since I've had mostly on client credentials in mind, this endpoint wasn't discussed that much. My impression is that this endpoint would mostly be used by non-constrained clients (towards the obviously non-constrained AS), and therefore it wouldn't need an ACE profiling, it could just be used as specified in OAuth. > > 11. Section 5.5.1 - OK - I am reversing thinking. However I need to get a > summary of what a profile is going to need to specify a long ways before I > get to this point. Perhaps has part of the overview. The summary of what a profile needs to specify is collected in Appendix C currently. This appendix reiterates points that are spread out (in contextually appropriate places) in the main body of the spec. > One of the questions > is going to be can the C-AS section of one profile be used with the C-RS of > another profile and keep the same security guarantees. The overview is > going to need to talk about this at some point. This seems to be a "it depends" issue. We should have some text on this, the security considerations seem the right place to me for this. Creating issue. > > 12. Section 5.5.1 - I would like to add some additional parameters at this > point. The first is a RS_Data field which is copied from the RS->C message > verbatim. It allows for encrypted data to be passed from the RS to the AS > as part of the request. Data type is COSE_Encrypt. Are you referring to the "nonce" that can be part of the AS discovery message? I'm not sure if that should go in this document or in a separate draft. What does the group think? > > 13. Section 5.5.1 - I would like to see an AS field documented here so th > that the 4 corner model can work. Could you be more specific about the "4 corner model"? I'm not familiar with that. > . > 14. Section 5.5.1 - What is the default - use this for "aud"? How is a > client supposed to know what to put here for a new RS? "aud" should contain be the identifier of the RS or a group of RS that the client wants to access. Since the client ought to know which RS it wants to access with the token, I assumed it would know what to put in this field. > > 15. Section 5.5.1 - on cnf - Use "It is RECOMMENDED that an AS reject a > request with a symmetric key" as this is positive and where enforcement is > done. Ok, fixed. > > 16. Figure 3 - This example no longer looks correct. the content type > should be the same as for Figure 2. That is assuming it is really CoAP and > not HTTP? Right, fixed. > > 17. Figure 4 - need to check out if client_secret is a real secret or not - > it seems odd to say don't use symmetric and then have an example of passing > one. Could be something else as I don't have RFC 6749 w/ me. True, this method is specified on section 2.3.1. of RFC 6749, so we thought we'd offer an example. I don't think this is a good feature security-wise. > > 18. The set of operations should start with the C->RS response structure > from DTLS profile as this is really the first thing that happens. Sounds reasonable, fixed in the discovery branch. Merge pending approval of my co-authors. > > 19. Is there a reason for a client not being able to request a profile > rather than having it be configured into the AS? We had that in a previous version and decided it was over-engineered. The client needs to be registered at the AS anyways, and could then also specify preferred profiles. > > 20. Section 5.5.2 - You are not being constant about encoding - this is > saying MUST be CBOR while earlier it was only a recommendation, Right, I'm adding an issue about this. We're also inconsistent in section 5.5.1. although not in RFC 2119 language. > 21. Section 5.5.2 - Post figure 5 it says examples - but only one example > exists. Fixed. > > 22. Section 5.5.4.2 - Please make the abbreviations mandatory not optional. > I don't really want to support both. I'll add an issue, I'm not opposed to that change, but I'd like to have consensus. (side note: Congratulations, you just contributed to creating the 100th issue on this draft on github) > > 23. Section 5.5.4.4 - Please define profile as being part of a CWT so that > it can be communicated to the RS in the event that more than one profile is > supported. Optional if RS only does one. Wouldn't the RS be able to determine the profile from the message it receives from the Client? Say the AS tells the client to use DTLS, the RS would notice receiving a DTLS handshake. Are there any scenarios where two profiles could be confused? > 24. Section 5.5.4.5 - I don't know if it would not be cleaner to have a cnf > that is only for the client key info and an rs_cnf (defined for > introspection) that is for dealing with the RS keysWe need to specify that the . That makes it cleaner > when looking a the case of an AS->C or an AS->R->C message as the fields > will be the same. Indeed I argued the same way, but I was voted down by my co-authors. I'll raise the issue again with your newfound support. > > 25. Section 5.5.4.5 - Figure 9 does not really make sense by itself. It > needs to have some context because it looks the same as for a RS key. Your point makes sense, but this whole section is going to be rewritten when we transfer cnf to draft-jones-ace-cwt-proof-of-possession. I'll take that into account when we do the rewrite. > > 26. Section 5.5.4.5 - Figure 10 is not formatted correctly as the map > wrapping is missing on unprotected. Correct, this figure is also bound to disappear, but I'll see that draft-jones gets the right example instead. > Look @ section 3.3. RFC 6749 about scopes That look more like a note to self to me, right? > > 27. Need to know how to think about the idea of a client doing an > introspection. Is the response going to be different than a RS doing the > query? I assume that the distinction would be based on the authentication > and internal knowledge - does not need to be documented except for response > differences. You mean if a client would do introspection on an access token it received? Depending on the AS its not sure it would be authorized to do so (mine has policies for determining who gets to introspect). I believe this can be left to the implementers. I might be convinced that it needs a security consideration though (if you insist).We need to specify that the > > 28. Figure 14 needs to be updated Done. > > 29. Section 5.6.2 - Need to add rs_UZWab0RScnf - if more than one key need to tell > the RS what key to use. I agree. Issue created > > 30. Section 5.6.4 - I think this is a required item if introspection is > going to be able to return a random symmetric key. Not needed otherwise. It could also be used to inform the client about the RS's public key for authentication. > > 31. Section 5.6.4 - last para - may want to state that this secret is > established at the same time that the token is established. Sounds reasonable. Fixed. > 32. Section 5.6.4 - establish MTI algorithms here? For encrypting the client token? Is that really necessary? The AS should know what algorithms the client supports. > > 33. Section 5.7 - I think that you need to add rs_cnf in the event of an RS > w/ multiple keys so it knows which to use. usage would be optional. > Agree. I'm extending the existing issue from 31. > 34. Section 5.7 - last paragraph - should be JOSE and COSE not JSON and > CBOR. Right, fixed. > > 35. Section 5.7.1 - Why would the RS respond with the cti - given a lack of > text it is not clear when the MAY would be triggered. It's just a suggestion to the implementer, not really necessary but useful in some scenarios (e.g. if the client later wants to delete or overwrite the token this could be good to have). > > 36. Section 5.7.1 - Not sure how much information is being leaked by having > different error codes being returned in these situations. May only want to > have one code. This is a difficult one. One the one hand you are right some information is leaked, but on the other hand, withholding that information makes it very hard for the client to fix erroneous access tokens. > > 37. Section 5.7.1 - under what circumstances is the introspection request > not made? If the RS is not configured to do so. E.g. if it has intermittent connectivity and the token is self contained. > If the introspection request is done async how is the client > token communicated back to the client? Would that be done as part of a > later access. Seems to be dicey. It's not designed to be done async. We should mention that. Issue created. > 38. Random thought - Is there a requirement that the same method be used > for both posting to /authz-info and to the resource? Could one use OSCOAP > for one and DTLS for the other? Question is because we are profiling and > the assumption is that profiles are whole. I'm assuming that /authz-info can be unprotected. It could use DTLS without client authentication, but it cannot use OSCOAP with a client that is not previously known, since the token sent to /authz-info contains necessary information to generate the OSCOAP context. > > 39. Section 5.7.2 - Last bullet - should note that tokens need to be shared > to the RS - AS may issue lots of tokens but if RS gets none then no > expirations I think that bullet is the best we can do in the described usecase. The last bullet refers to a RS that has not clock at all and no connectivity to the AS. If the RS had connectivity it could do introspection. If you have a better suggestion I'm open for suggestions. > > 40. Section 5.7.2 - Another "long running request" might be the case of > sending back an ACK for a request followed by a 4.01 because the token > expires before the request has finished processing. Re-doing introspection > might also cause this sequence of messages > Do you think it would be useful to give these additional examples? > 41. Section 6 - personal preference - remove the first sentence it is not > useful. I agree, I've heard this more than once now. > > 42. Section 6 - Protection is from signature or MAC - but we are using AEAD > for most of these. Should probably have a security consideration that AEAD > is preferred to MAC in most cases because of confidentiality as well. > Agree, fixed. > 43. Section 6- the phrase 'long-term key shared with RS' implies to me that > this is a symmetric key. May want different language to allow for people > thinking of asymmetric keys as well. > Fixed. > 44. Section 6 - Please explain to me how targeting multiple RS with an > asymmetric key is a problem - change it form shared secret to symmetric key. Yes that sounds like something that was meant to apply for symmetric keys, which is NOT RECOMMENDED anyways some paragraphs above. Fixed. > > 45. Section 6- I think you want to use a different term than token replay > in this paragraph. If a RS is rebooted and loses all token information, > there is nothing wrong with a C doing a replay of the token to the RS to get > access to the resources as long as it is still valid. I reworded the whole paragraph. > > 46. Section 6 - Is the confidentiality protection a requirement for > asymmetric keys as well? -- Oh - and it may not be a session key, the > session key for DTLS is established later, it is just a POP value (or key if > asymmetric) That issue relates to your point made in 9. I'll update the issue to consider this as well. I also replaced "session key" with "proof-of-possession key". > > 47. Section 6 - Sentence structure of this paragraph is difficult. The AS > does not use shorter key sizes, it will perhaps create shorter POP keys. > However, even this may be a problem depending on how short they are. A > tradeoff is going to occur here with the ability to record and later decrypt > keys depending how short the keys are. I've tried to rephrase that paragraph to clarify it. Please check again. > > 47. Section 6 - the next to last paragraph is a repeat - but probably > clearer. Fixed: I deleted the other paragraph. > > 48. Section 6 - Please explain the reasoning behind the last paragraph. It > does not make a great deal of sense to me. If you issue an access token bound to a symmetric pop-key that is valid for a group of RS, then any of these RS that receives the token can use to towards the other RS, impersonating the client. I'll try to clarify the text in the draft (I also noted that the context to using a symmetric pop key got lost in the second sentence of that paragraph). > > 49. Section 7 - I don't understand what you are trying to say with the last > sentence in the second paragraph. Given that the AS still needs to do ACL > control, this does not make sense to me. > In other grants, you have the authorization performed by the resource owner and the AS just validates the grant provided by the client. These grants can be used to hide the client's identity towards the AS. I'll reformulate to clarify. > For now I skipped IANA considerations and the appendixes. > Noted, those are probably bound to change a bit when we extract cnf. > Let me know if you would prefer that I place these items into the issue list > on github or if you prefer doing it. > > Jim > I'm creating issues as I go, thanks for the offer. -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Mon Aug 7 10:58:43 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BA413203D for ; Mon, 7 Aug 2017 10:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com 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 BUZwXrfznAoU for ; Mon, 7 Aug 2017 10:58:29 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1569D131D19 for ; Mon, 7 Aug 2017 10:57:47 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1502128638; h=from:subject:to:date:message-id; bh=Gam/sOb/akqUwZFEzk2RBbaxoDVrmZb2gH+BkeA8h3w=; b=RsMA1JVbz3o3YnRKGdoTnn8cc1QGDUUeGvrBFsysEnqcwE6FYJEduMgX71Aha2upMoOqWW2QoZh /7pR+4xRS5gB4LCfIGTq0nxJLXIBzCoCJWuOcaGktPmWL28NgPyf+Tm8MIZqTStmn75w+mmFznwXg X9dK4UR7qNmn5zlUw0C+7ONGmdZ2gFHqEmk4ubDk9YvUi3QxqZ0VTz3HLyKDNiSbj++K3VEIbHD/t A9ZGX8Y62sLkVxG3Fc4LYcvgOAC0icLAAT3PSxMwav7R1nNTBhzDMglMPGrzhoRP5M/dIxsG6DfJv ljHMKUQtOE2vcF6Bma95VgIxU/p5pfKDuCbw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 7 Aug 2017 10:57:17 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 7 Aug 2017 10:56:54 -0700 From: Jim Schaad To: 'Ludwig Seitz' , References: <03aa01d30d6a$6c336b80$449a4280$@augustcellars.com> <440e7514-da45-1633-5ec9-1134d6a1c079@ri.se> In-Reply-To: <440e7514-da45-1633-5ec9-1134d6a1c079@ri.se> Date: Mon, 7 Aug 2017 10:57:16 -0700 Message-ID: <007901d30fa6$9d383290$d7a897b0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHstV3t2SC9xop8bZ73ZGhutLCNNwIDQl0lojWqEEA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-oauth-authz-06 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 17:58:33 -0000 Responses in line, I have trimmed things which did not seem to need a response. Jim > -----Original Message----- > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Ludwig Seitz > Sent: Monday, August 7, 2017 6:04 AM > To: ace@ietf.org > Subject: Re: [Ace] Review of draft-ietf-ace-oauth-authz-06 > > On 2017-08-04 23:41, Jim Schaad wrote: > > As promised I finally got finished with this review. > > Thank you for your very thorough review Jim. Comments inline (note that > there are a few questions as well). > > /Ludwig > > > > > > 1. Need to decide if /token, /introspect and /authz-info are under > > /.well-defined or not. If they are then this needs to be noted and > > there needs to be an IANA action if this has not already been done for > OAuth. > > I've added an issue to our issue tracker on this. However I would think that > this is something that would need to apply to OAuth as well. I would agree that it makes sense to have OAuth deal with this issue as well. It is probably less of an issue for /token if the client always gets this from the RS and does not try to find it on its own. The /authz-info point is probably more significant. Be sure to catch Olaf's comment on using a resource type as another way to identify this. > > > > 3. Still unhappy about the lack of POP between C and AS. How does the AS > > know that the key it is binding to the token is the right one. The RS has > > no problems, but assumes that the AS did its job. > > I'm not sure what problem that would solve. That C binds the token to a > key it doesn't own? What benefit would C have from that? > > If C wants to relay a token to a "friend" it could always share the > pop-key with said friend. If I can fool C into thinking that my key is it's key, when the process is finished the RS has an access token with the privileges of C, but with my key. I now can do anything that C would be able to do. This would only need to be done the first time the AC sees the key as it could keep track that the key is associated with C for later requests. > > > > 4. If I want to use the SCOPES field as defined by Carsten, then I do not > > want the current restriction that is being imposed on the scope parameter > in > > Section 3 (?) Under "Scopes and Permissions". > > I'm just reiterating the definition of the scope parameter from the > OAuth spec. I think Carsten's approach can be modified to fit into that > spec. A sentence that says that other methods of doing scopes is permitted would satisfy my desires. > > > > 7. In section 4 - Under "ACE Profiles" - RECOMMENDS seems to be an odd > > thing to have here - this is not really a protocol recommendation is it? > > Are we allowing for JSON to be used rather than CBOR? The text here on > what > > encodings to use could be made more declarative. Are we expecting any > JSON > > use at this point for any profile define? If so then a list of tradeoffs > > for profile creators and how to detect would be in order rather than the big > > RECOMMENDS. > > You mean section 5 right? Yes - this should have been section 5. > > Yes the intention is to allow profiles to specify JSON (or something > else) as data format instead of CBOR. If one were to be using JSON why would one not just use OAuth rather than ACE? If JSON is really going to be a legal option then I think it should be fully fleshed out as part of this document. Otherwise you might end up with MTI problems. > > 10. Section 5.4 appears to create a new endpoint that has not been > > discussed in other contexts. Is this intentional? > > No that's just an existing OAuth endpoint. Since I've had mostly on > client credentials in mind, this endpoint wasn't discussed that much. > > My impression is that this endpoint would mostly be used by > non-constrained clients (towards the obviously non-constrained AS), and > therefore it wouldn't need an ACE profiling, it could just be used as > specified in OAuth. You might think about moving the out-of-scope statement closer to the front of the section so that is clearer. > > > > > 11. Section 5.5.1 - OK - I am reversing thinking. However I need to get a > > summary of what a profile is going to need to specify a long ways before I > > get to this point. Perhaps has part of the overview. > > The summary of what a profile needs to specify is collected in Appendix > C currently. This appendix reiterates points that are spread out (in > contextually appropriate places) in the main body of the spec. You should have an early pointer to this so people know it is there and read it then. > > > > One of the questions > > is going to be can the C-AS section of one profile be used with the C-RS of > > another profile and keep the same security guarantees. The overview is > > going to need to talk about this at some point. > > This seems to be a "it depends" issue. We should have some text on this, > the security considerations seem the right place to me for this. > Creating issue. I think that this should be part of the "main" text and goes to what St Johns (I think it was him) brought up at the mic where it needs to be clear someplace what the security assumptions/requirements are for each leg of the conversation are that a profile needs to be sure to include. And how using different profiles might interact. > > 12. Section 5.5.1 - I would like to add some additional parameters at this > > point. The first is a RS_Data field which is copied from the RS->C message > > verbatim. It allows for encrypted data to be passed from the RS to the AS > > as part of the request. Data type is COSE_Encrypt. > > Are you referring to the "nonce" that can be part of the AS discovery > message? I'm not sure if that should go in this document or in a > separate draft. What does the group think? I am referring to more than just the "nonce" value, although that is one such value. If you look at draft-cuellar-ace-pat-priv-enhanced-authz-tokens in section 4.3, they have a whole set of parameters that are to be transferred from the RS to the AS via C. One some parameter would be the RS having an idea of what the scope is that needs to be authorized based on the request (thus allowing C not to have to understand scopes). > > 13. Section 5.5.1 - I would like to see an AS field documented here so th > > that the 4 corner model can work. > > Could you be more specific about the "4 corner model"? I'm not familiar > with that. It is an old term that I learned early on in my career which actually refers to how your credit card is setup to get authorized. You have four parties one on each corner - Card holder, Card Bank, Merchant bank, Merchant. Looks just the security model from actors if you omit the owners. This is basically short hand for saying that CAS != AS. > > 14. Section 5.5.1 - What is the default - use this for "aud"? How is a > > client supposed to know what to put here for a new RS? > > "aud" should contain be the identifier of the RS or a group of RS that > the client wants to access. > > Since the client ought to know which RS it wants to access with the > token, I assumed it would know what to put in this field. So the answer is [2001::1]? > > 17. Figure 4 - need to check out if client_secret is a real secret or not - > > it seems odd to say don't use symmetric and then have an example of > passing > > one. Could be something else as I don't have RFC 6749 w/ me. > > True, this method is specified on section 2.3.1. of RFC 6749, so we > thought we'd offer an example. > > I don't think this is a good feature security-wise. That is for Client Password authorization - This is not going to be something that you ever want to support in this profile. There are other better ways to deal with a shared secret and you don't want the potential multiple round trips to do http authorization here. > > 19. Is there a reason for a client not being able to request a profile > > rather than having it be configured into the AS? > > We had that in a previous version and decided it was over-engineered. > The client needs to be registered at the AS anyways, and could then also > specify preferred profiles. The AS also needs to know the network layout as well since C and RS may not be able to use DTLS if they need to go through a proxy. > > 23. Section 5.5.4.4 - Please define profile as being part of a CWT so that > > it can be communicated to the RS in the event that more than one profile is > > supported. Optional if RS only does one. > > Wouldn't the RS be able to determine the profile from the message it > receives from the Client? > > Say the AS tells the client to use DTLS, the RS would notice receiving a > DTLS handshake. Are there any scenarios where two profiles could be > confused? Say the AS tells the client to use DTLS. C then posts the token to /authz-info. Is this DTLS, OSCOAP, PAT, IPSec? > > Look @ section 3.3. RFC 6749 about scopes > > That look more like a note to self to me, right? Yes this was a note to self. > > > > > 27. Need to know how to think about the idea of a client doing an > > introspection. Is the response going to be different than a RS doing the > > query? I assume that the distinction would be based on the authentication > > and internal knowledge - does not need to be documented except for > response > > differences. > > You mean if a client would do introspection on an access token it > received? Depending on the AS its not sure it would be authorized to do > so (mine has policies for determining who gets to introspect). I believe > this can be left to the implementers. I might be convinced that it needs > a security consideration though (if you insist).We need to specify that the The first sentence of section 5.6 says that the client can query for the introspection point. I this is not what is desired then just remove that. If it is desired, then I assume that some of the response elements would be different. If so then that needs to be documented. > > 30. Section 5.6.4 - I think this is a required item if introspection is > > going to be able to return a random symmetric key. Not needed otherwise. > > It could also be used to inform the client about the RS's public key for > authentication. True - either way I support having this. > > 32. Section 5.6.4 - establish MTI algorithms here? > > For encrypting the client token? Is that really necessary? The AS should > know what algorithms the client supports. That is fine, until I have an AS that only does CCM and a client which only does ChaCha-Poly1305. > > 35. Section 5.7.1 - Why would the RS respond with the cti - given a lack of > > text it is not clear when the MAY would be triggered. > > It's just a suggestion to the implementer, not really necessary but > useful in some scenarios (e.g. if the client later wants to delete or > overwrite the token this could be good to have). This is not at all clear or documented. > > 36. Section 5.7.1 - Not sure how much information is being leaked by having > > different error codes being returned in these situations. May only want to > > have one code. > > This is a difficult one. One the one hand you are right some information > is leaked, but on the other hand, withholding that information makes it > very hard for the client to fix erroneous access tokens. Should probably have a security consideration on this. > > 37. Section 5.7.1 - under what circumstances is the introspection request > > not made? > > If the RS is not configured to do so. E.g. if it has intermittent > connectivity and the token is self contained. That was assumed. The question is what are you doing in the 3rd to last paragraph where you say the RS MAY introspect. But does not say anything about when or why. I would take it as a given that if the token is self-contained then it would never been done. > > > If the introspection request is done async how is the client > > token communicated back to the client? Would that be done as part of a > > later access. Seems to be dicey. > > It's not designed to be done async. We should mention that. Issue created. > > > 40. Section 5.7.2 - Another "long running request" might be the case of > > sending back an ACK for a request followed by a 4.01 because the token > > expires before the request has finished processing. Re-doing introspection > > might also cause this sequence of messages > > > > Do you think it would be useful to give these additional examples? I am not really happy with how the paragraph is designed. But no they probably do not help. > > 48. Section 6 - Please explain the reasoning behind the last paragraph. It > > does not make a great deal of sense to me. > > If you issue an access token bound to a symmetric pop-key that is valid > for a group of RS, then any of these RS that receives the token can use > to towards the other RS, impersonating the client. > > I'll try to clarify the text in the draft (I also noted that the context > to using a symmetric pop key got lost in the second sentence of that > paragraph). The problem with that statement is that the client is using an asymmetric key pair here. > > For now I skipped IANA considerations and the appendixes. > > > Noted, those are probably bound to change a bit when we extract cnf. >From previous comments, looks like I should think about reading the appendixes though. By the way, a quick republish to update email addresses might be desirable so that the author list does not send back so many bounces. > > > Let me know if you would prefer that I place these items into the issue list > > on github or if you prefer doing it. > > > > Jim > > > > I'm creating issues as I go, thanks for the offer. > > > > -- > Ludwig Seitz, PhD > Security Lab, RISE SICS > Phone +46(0)70-349 92 51 > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Mon Aug 7 17:33:16 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AEB124BE8 for ; Mon, 7 Aug 2017 17:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com 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 qN8epy_yMqT1 for ; Mon, 7 Aug 2017 17:33:13 -0700 (PDT) Received: from out0-200.mail.aliyun.com (out0-200.mail.aliyun.com [140.205.0.200]) by ietfa.amsl.com (Postfix) with ESMTP id CCB49131CEC for ; Mon, 7 Aug 2017 17:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1502152390; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=GSJsUXjutab69DulutHWKAACIvNR2q5WLX/x5iSqL60=; b=Hk7UCY9smWmPOv9NRVNrZwGDffj+MGS3ioDgPeIEHkx/DWtzUK3rh9OGgUkHpNn8cc/OQOdSjXE6tLJ3KwQx/ZmXzHHqZuYlrdDJL4ibop3KmKGqYB6jEajGwzVOaqQG4x8dCmJpWoSWAjsxcHKnAkKlwxjFCyE0oIoExmEFFj8= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R171e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03305; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=4; SR=0; TI=SMTPD_---.8bzFQFL_1502152380; Received: from 30.6.252.3(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.246) by smtp.aliyun-inc.com(127.0.0.1); Tue, 08 Aug 2017 08:33:05 +0800 User-Agent: Microsoft-MacOutlook/14.6.8.160830 Date: Tue, 08 Aug 2017 08:33:01 +0800 From: "Kepeng Li" To: "Kepeng Li" , CC: Kathleen Moriarty , "Hannes.Tschofenig@gmx.net" Message-ID: Thread-Topic: [Ace] Call for adoption of draft-jones-ace-cwt-proof-of-possession Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3585025987_4408970" Archived-At: Subject: [Ace] Call for adoption of draft-jones-ace-cwt-proof-of-possession X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 00:33:16 -0000 > 此邮件使用 MIME 格式。由于邮件阅读程序不能识别 此格式，因此，可能无法识别该邮件的分部或部分内容。 --B_3585025987_4408970 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hello all, In the IETF 99 F2F meeting, Mike Jones made the case for working group adoption of draft-jones-ace-cwt-proof-of-possession [1] in his presentation https://www.ietf.org/proceedings/99/slides/slides-99-ace-cwt-proof-of-posses sion-00.pdf. Afterwards, a hum was taken and there was clear support for adoption in the room. Several people also spoke up for adoption at the microphone and no one spoke against it. This note is asking for confirmation of this tentative adoption decision on the mailing list. Please speak up before 22nd Aug, 2017 if you would like to register your opinion on the adoption question. Keep in mind that adoption of a document does not mean the document as-is is ready for publication. It is merely acceptance of the document as a starting point for what will be the final product of the ACE working group. The working group is free to make changes to the document according to the normal consensus process. Please reply on this thread with expressions of support or opposition, preferably with comments, regarding accepting this as a work item. Thanks Kind Regards Kepeng and Hannes (ACE co-chairs) [1] https://datatracker.ietf.org/doc/draft-jones-ace-cwt-proof-of-possession/ --B_3585025987_4408970 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hello all,
 <=
/font>

In the IETF 99 F2F= meeting, Mike Jones made the case for working group adoption of draft-jones= -ace-cwt-proof-of-possession [1] in his presentation https://www.ietf.org/proceedings/99/sl= ides/slides-99-ace-cwt-proof-of-possession-00.pdf.  Afterwards, a h= um was taken and there was clear support for adoption in the room.  Sev= eral people also spoke up for adoption at the microphone and no one spoke ag= ainst it.

 

This note is asking for confirma= tion of this tentative adoption decision on the mailing list.  Please s= peak up before 22nd Aug, 2017 if you would like to register your opinion on = the adoption question.


<= div>
Keep in mind tha=
t adoption of a document does not mean the document as-is is ready for publi=
cation. It is merely acceptance of the document as a starting point for what=
 will be the final product of the ACE working group. The working group is fr=
ee to make changes to the document according to the normal consensus process=
.
 
Please reply=
 on this thread with expressions of support or opposition, preferably with c=
omments, regarding accepting this as a work item.

 

Thanks
 
Kind Regards
Kepeng and Hannes (ACE co-chairs)
=


--B_3585025987_4408970-- From nobody Mon Aug 7 18:33:28 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858B91243F6 for ; Mon, 7 Aug 2017 18:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 AuJWpnvVApT5 for ; Mon, 7 Aug 2017 18:33:23 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0125.outbound.protection.outlook.com [104.47.36.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EDDD124207 for ; Mon, 7 Aug 2017 18:33:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pbGYK7HmvfApwF+uYZoYOgJS/qJ0HP9cQ7vhHsqVp3U=; b=XtZETIM7o0CmCp/oJnFwdsMEIIfaHmQvz4wNAv3eqaVHboqlLX7dgyn+b+SStylo9fWCmZ13JgJz80dez45sOS51K3yUK59QiyeFmGWB8f3Wo5AnCBSwlUYBafYFjjON2oKHyN4hG/sV7TmdaiaJPlVuXmBKtxx50dNpVqeFCPY= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0280.namprd21.prod.outlook.com (10.173.193.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.0; Tue, 8 Aug 2017 01:33:03 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1362.000; Tue, 8 Aug 2017 01:33:03 +0000 From: Mike Jones To: Kepeng Li , "Ace@ietf.org" CC: Kathleen Moriarty , "Hannes.Tschofenig@gmx.net" Thread-Topic: [Ace] Call for adoption of draft-jones-ace-cwt-proof-of-possession Thread-Index: AQHTD93y0HtqA3N0G0yfB6MTXl1kIaJ5nM3w Date: Tue, 8 Aug 2017 01:33:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-08-07T18:33:01.9450347-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:4::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0280; 6:HGhhrnWM+hPT7L9OH6njDzi1Ugq+kX0YNyOHkSRethh5SOgrCXPOPa4aLt1Ipjpyi8wGXAH1Jg9bwfr3mrK9Tw4k1x5HhMEBuF35Lns6bTIwyjzuUagH977ve14j32KWRH4pmLcsyHJGSsLhNkiLQr2/Ey863MbYsa5GoGnZrdR5lhzSIJtpWDxb0YTlA5lm+xQPPEve6SoCOOM1xzV3su/t/9SR+UnQrHiD6+IJNFchLEhcoggevknL5XTMuriuc23JGPpjUqTSctf7yKRxUuWJjmEaa0AmZJm3m4DhnvlBGBHhiQ7Kafu4RsKkr+8NyO9DbwEqaKK46Rx5KLCw1g==; 24:BxTgyD81b5b9mCo4C9wV/3p2F4uaZU+E9w30fd3Ve/B5Cd0fP4uA7tQ6w60UiNlJGqNyFXBRFbsDAy8T+vPROTjtgwd+X6kbLsjB2XQuQNw=; 7:uYV6RzVqcMzlnht6qYnwR8mpjL8+BGgVdDiA8tkcLmBn91zyXt4bhU7ggOMntvDuyLdI5KBQkQ+61wviQZGgJ0vrVQOg2j8rLaw/O2XRVj9Vn+gKXt/GLv8pKqEp3Biv98vCOUwyW9JWLUPaXdZ9r3balQF7CsOv1GI6FqgJaVQjPDSWWBL2H3tmHN1yaVz2Y1aLYoSeB531p49drOO49BljVBqKBT5umVS302hmeZ4= x-ms-office365-filtering-correlation-id: 43a9955a-acc5-40d2-0619-08d4ddfd69d3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603123)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR21MB0280; x-ms-traffictypediagnostic: CY4PR21MB0280: x-forefront-prvs: 03932714EB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(47760400005)(377454003)(189002)(199003)(53754006)(2501003)(81156014)(8676002)(33656002)(6506006)(74316002)(5660300001)(10090500001)(189998001)(2950100002)(86362001)(77096006)(86612001)(97736004)(229853002)(6246003)(39060400002)(7736002)(6436002)(68736007)(101416001)(7696004)(54906002)(55016002)(99286003)(54896002)(9686003)(236005)(6306002)(54356999)(76176999)(50986999)(105586002)(2900100001)(966005)(606006)(72206003)(53546010)(14454004)(8990500004)(230783001)(106356001)(4326008)(19609705001)(5005710100001)(3280700002)(10290500003)(25786009)(3660700001)(8936002)(102836003)(6116002)(790700001)(564094006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0280; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB05041D8457CDB4FEBD2B81C1F58A0CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2017 01:33:03.6578 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0280 Archived-At: Subject: Re: [Ace] Call for adoption of draft-jones-ace-cwt-proof-of-possession X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 01:33:26 -0000 --_000_CY4PR21MB05041D8457CDB4FEBD2B81C1F58A0CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for doing this, Kepeng. I obviously support adoption. Soon after -00 working group draft is there, we'll also plan to post a -01 = draft with some improvements suggested by Ludwig. Best wishes= , -- Mike From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Kepeng Li Sent: Monday, August 7, 2017 5:33 PM To: Kepeng Li ; Ace@ietf.org Cc: Kathleen Moriarty ; Hannes.Tschofenig= @gmx.net Subject: [Ace] Call for adoption of draft-jones-ace-cwt-proof-of-possession Hello all, In the IETF 99 F2F meeting, Mike Jones made the case for working group adop= tion of draft-jones-ace-cwt-proof-of-possession [1] in his presentation htt= ps://www.ietf.org/proceedings/99/slides/slides-99-ace-cwt-proof-of-possessi= on-00.pdf. Afterwards, a hum was taken and there was clear support for ado= ption in the room. Several people also spoke up for adoption at the microp= hone and no one spoke against it. This note is asking for confirmation of this tentative adoption decision on= the mailing list. Please speak up before 22nd Aug, 2017 if you would like= to register your opinion on the adoption question. Keep in mind that adoption of a document does not mean the document as-is i= s ready for publication. It is merely acceptance of the document as a start= ing point for what will be the final product of the ACE working group. The = working group is free to make changes to the document according to the norm= al consensus process. Please reply on this thread with expressions of support or opposition, pref= erably with comments, regarding accepting this as a work item. Thanks Kind Regards Kepeng and Hannes (ACE co-chairs) [1] https://datatracker.ietf.org/doc/draft-jones-ace-cwt-proof-of-possessio= n/ --_000_CY4PR21MB05041D8457CDB4FEBD2B81C1F58A0CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for doing this,= Kepeng.  I obviously support adoption.

 

Soon after -00 working= group draft is there, we’ll also plan to post a -01 draft with some = improvements suggested by Ludwig.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          Best wishes,<= /o:p>

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          -- Mike=

 

From: Ace [mailto:ace-bounces@ietf.org] On= Behalf Of Kepeng Li
Sent: Monday, August 7, 2017 5:33 PM
To: Kepeng Li <kepeng.lkp@alibaba-inc.com>; Ace@ietf.org
Cc: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>; Hann= es.Tschofenig@gmx.net
Subject: [Ace] Call for adoption of draft-jones-ace-cwt-proof-of-pos= session

 

Hello all,

 

In the IETF 99 F2F meeting, Mike Jones made the case for wor= king group adoption of draft-jones-ace-cwt-proof-of-possession [1] in his p= resentation htt= ps://www.ietf.org/proceedings/99/slides/slides-99-ace-cwt-proof-of-possessi= on-00.pdf.  Afterwards, a hum was taken and there was clear support for adoption in th= e room.  Several people also spoke up for adoption at the microphone a= nd no one spoke against it.

 <= /p>

This note is asking for confirmation of this tentative adopt= ion decision on the mailing list.  Please speak up before 22nd Aug, 20= 17 if you would like to register your opinion on the adoption question.

 = 

Keep in mind that adoption =
of a document does not mean the document as-is is ready for publication. It=
 is merely acceptance of the document as a starting point for what will be =
the final product of the ACE working group. The working group is free to ma=
ke changes to the document according to the normal consensus process.
 
Please reply on this thread=
 with expressions of support or opposition, preferably with comments, regar=
ding accepting this as a work item.=

  

Thanks
 =

Kind Regards<=
/span>
Kepeng and Hannes (ACE co-chairs)

 





--_000_CY4PR21MB05041D8457CDB4FEBD2B81C1F58A0CY4PR21MB0504namp_-- From nobody Tue Aug 8 08:02:16 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E319D1324E6 for ; Tue, 8 Aug 2017 08:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 lracDXGRpWnH for ; Tue, 8 Aug 2017 08:02:12 -0700 (PDT) Received: from se-out2.mx-wecloud.net (se-out2.mx-wecloud.net [89.221.255.177]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A64A81324AE for ; Tue, 8 Aug 2017 08:02:11 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out2.mx-wecloud.net (Postfix) with ESMTPS id C390E221A28; Tue, 8 Aug 2017 15:02:06 +0000 (UTC) Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Tue, 8 Aug 2017 17:01:15 +0200 From: Ludwig Seitz To: Jim Schaad , References: <03aa01d30d6a$6c336b80$449a4280$@augustcellars.com> <440e7514-da45-1633-5ec9-1134d6a1c079@ri.se> <007901d30fa6$9d383290$d7a897b0$@augustcellars.com> Message-ID: Date: Tue, 8 Aug 2017 17:02:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <007901d30fa6$9d383290$d7a897b0$@augustcellars.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=PqbjV0E3 c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=IkcTkHD0fZMA:10 a=KeKAF7QvOSUA:10 a=133b1qdXcu7K-i0hmyoA:9 a=zyNg-EufZMlSQws_:21 a=uG_h4JQ6YTrJJXe2:21 a=QEXdDO2ut3YA:10 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-oauth-authz-06 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 15:02:16 -0000 On 2017-08-07 19:57, Jim Schaad wrote: >>> >>> 3. Still unhappy about the lack of POP between C and AS. How does the > AS >>> know that the key it is binding to the token is the right one. The RS > has >>> no problems, but assumes that the AS did its job. >> >> I'm not sure what problem that would solve. That C binds the token to a >> key it doesn't own? What benefit would C have from that? >> >> If C wants to relay a token to a "friend" it could always share the >> pop-key with said friend. > > If I can fool C into thinking that my key is it's key, when the process is > finished the RS has an access token with the privileges of C, but with my > key. I now can do anything that C would be able to do. This would only > need to be done the first time the AC sees the key as it could keep track > that the key is associated with C for later requests. > Ok, we could fix this by requiring that the key used by C when authenticating to AS is the one that is used as PoP key. >>> >>> 4. If I want to use the SCOPES field as defined by Carsten, then I do > not >>> want the current restriction that is being imposed on the scope > parameter >> in >>> Section 3 (?) Under "Scopes and Permissions". >> >> I'm just reiterating the definition of the scope parameter from the >> OAuth spec. I think Carsten's approach can be modified to fit into that >> spec. > > A sentence that says that other methods of doing scopes is permitted would > satisfy my desires. I would favor a solution that says that scopes are strings by default, unless the AS and the RS specifically agree on something else. That way an implementation does not have to deal with binary data by default. >>> >>> 7. In section 5 - Under "ACE Profiles" - RECOMMENDS seems to be an odd >>> thing to have here - this is not really a protocol recommendation is it? >>> Are we allowing for JSON to be used rather than CBOR? The text here on >> what >>> encodings to use could be made more declarative. Are we expecting any >> JSON >>> use at this point for any profile define? If so then a list of > tradeoffs >>> for profile creators and how to detect would be in order rather than the > big >>> RECOMMENDS. >> Yes the intention is to allow profiles to specify JSON (or something >> else) as data format instead of CBOR. > > If one were to be using JSON why would one not just use OAuth rather than > ACE? If JSON is really going to be a legal option then I think it should be > fully fleshed out as part of this document. Otherwise you might end up with > MTI problems. Sounds reasonable to me, I'll propose that change > >>> 10. Section 5.4 appears to create a new endpoint that has not been >>> discussed in other contexts. Is this intentional? >> >> No that's just an existing OAuth endpoint. Since I've had mostly on >> client credentials in mind, this endpoint wasn't discussed that much. >> >> My impression is that this endpoint would mostly be used by >> non-constrained clients (towards the obviously non-constrained AS), and >> therefore it wouldn't need an ACE profiling, it could just be used as >> specified in OAuth. > > You might think about moving the out-of-scope statement closer to the front > of the section so that is clearer. > Ok I will try to clarify this. >> >>> >>> 11. Section 5.5.1 - OK - I am reversing thinking. However I need to get > a >>> summary of what a profile is going to need to specify a long ways before > I >>> get to this point. Perhaps has part of the overview. >> >> The summary of what a profile needs to specify is collected in Appendix >> C currently. This appendix reiterates points that are spread out (in >> contextually appropriate places) in the main body of the spec. > > You should have an early pointer to this so people know it is there and read > it then. > Done. >> >> >>> One of the questions >>> is going to be can the C-AS section of one profile be used with the C-RS of >>> another profile and keep the same security guarantees. The overview is >>> going to need to talk about this at some point. >> >> This seems to be a "it depends" issue. We should have some text on this, >> the security considerations seem the right place to me for this. >> Creating issue. > > I think that this should be part of the "main" text and goes to what St > Johns (I think it was him) brought up at the mic where it needs to be clear > someplace what the security assumptions/requirements are for each leg of the > conversation are that a profile needs to be sure to include. And how using > different profiles might interact. > Note that in discussion with Hannes today, he came up with the very reasonable scenario of C<->AS with DTLS/CoAP and C<->RS with TLS/MQTT. >>> 12. Section 5.5.1 - I would like to add some additional parameters at > this >>> point. The first is a RS_Data field which is copied from the RS->C > message >>> verbatim. It allows for encrypted data to be passed from the RS to the > AS >>> as part of the request. Data type is COSE_Encrypt. >> >> Are you referring to the "nonce" that can be part of the AS discovery >> message? I'm not sure if that should go in this document or in a >> separate draft. What does the group think? > > I am referring to more than just the "nonce" value, although that is one > such value. If you look at draft-cuellar-ace-pat-priv-enhanced-authz-tokens > in section 4.3, they have a whole set of parameters that are to be > transferred from the RS to the AS via C. One some parameter would be the RS > having an idea of what the scope is that needs to be authorized based on the > request (thus allowing C not to have to understand scopes). I would be in favor of moving these things into a separate document. The current draft is already quite long, and it doesn't feel like essential functionality to me. >>> 13. Section 5.5.1 - I would like to see an AS field documented here so > th >>> that the 4 corner model can work. >> >> Could you be more specific about the "4 corner model"? I'm not familiar >> with that. > > It is an old term that I learned early on in my career which actually refers > to how your credit card is setup to get authorized. You have four parties > one on each corner - Card holder, Card Bank, Merchant bank, Merchant. Looks > just the security model from actors if you omit the owners. This is > basically short hand for saying that CAS != AS. The the 4 corner model would use the CAS as intermediary between C and AS. This means on the one hand that the CAS would need some token request parameters that indicate for which client it is requesting a token from the AS. On the other hand the client could query the CAS just like it queries the AS /token endpoint, so I don't see an immediate need for measures on that side of the communication. Since I haven't seen strong industry demands for supporting the CAS so far, I'd suggest to move such specifications into a separate document. > >>> 14. Section 5.5.1 - What is the default - use this for "aud"? How is a >>> client supposed to know what to put here for a new RS? >> >> "aud" should contain be the identifier of the RS or a group of RS that >> the client wants to access. >> >> Since the client ought to know which RS it wants to access with the >> token, I assumed it would know what to put in this field. > > So the answer is [2001::1]? For example, or just "aud" : "myTemperatureSensors", where the RS and the AS have a mapping of which RS correspond to "myTemperateSensors". > >>> 17. Figure 4 - need to check out if client_secret is a real secret or > not - >>> it seems odd to say don't use symmetric and then have an example of >> passing >>> one. Could be something else as I don't have RFC 6749 w/ me. >> >> True, this method is specified on section 2.3.1. of RFC 6749, so we >> thought we'd offer an example. >> >> I don't think this is a good feature security-wise. > > That is for Client Password authorization - This is not going to be > something that you ever want to support in this profile. There are other > better ways to deal with a shared secret and you don't want the potential > multiple round trips to do http authorization here. Indeed. I will modify that example to use some other method. > >>> 19. Is there a reason for a client not being able to request a profile >>> rather than having it be configured into the AS? >> >> We had that in a previous version and decided it was over-engineered. >> The client needs to be registered at the AS anyways, and could then also >> specify preferred profiles. > > The AS also needs to know the network layout as well since C and RS may not > be able to use DTLS if they need to go through a proxy. These kind of things should be covered implicitly since RS and C are registered at the AS together with a list fo the profiles they support. I would expect that if either C or RS are deployed on a network that requires proxies, DTLS will simply not be a supported profile. > >>> 23. Section 5.5.4.4 - Please define profile as being part of a CWT so > that >>> it can be communicated to the RS in the event that more than one profile > is >>> supported. Optional if RS only does one. >> >> Wouldn't the RS be able to determine the profile from the message it >> receives from the Client? >> >> Say the AS tells the client to use DTLS, the RS would notice receiving a >> DTLS handshake. Are there any scenarios where two profiles could be >> confused? > > Say the AS tells the client to use DTLS. C then posts the token to > /authz-info. Is this DTLS, OSCOAP, PAT, IPSec? Why would the RS need to know at that point? When a token is posted to /authz-info the only thing the RS needs to do is to make sure that it is valid and store it for future use. That does not require knowledge of the profile the client is going to use when requesting a resource later. >>> 27. Need to know how to think about the idea of a client doing an >>> introspection. Is the response going to be different than a RS doing > the >>> query? I assume that the distinction would be based on the > authentication >>> and internal knowledge - does not need to be documented except for >> response >>> differences. >> >> You mean if a client would do introspection on an access token it >> received? Depending on the AS its not sure it would be authorized to do >> so (mine has policies for determining who gets to introspect). I believe >> this can be left to the implementers. I might be convinced that it needs >> a security consideration though (if you insist).We need to specify that > the > > The first sentence of section 5.6 says that the client can query for the > introspection point. I this is not what is desired then just remove that. > > If it is desired, then I assume that some of the response elements would be > different. If so then that needs to be documented. Why would the response elements be different? The response is the claims associated to the token subject to introspection. They are the same regardless whether the client or the RS asks. It's another question whether they are meaningful to the client. > >>> 32. Section 5.6.4 - establish MTI algorithms here? >> >> For encrypting the client token? Is that really necessary? The AS should >> know what algorithms the client supports. > > That is fine, until I have an AS that only does CCM and a client which only > does ChaCha-Poly1305. I see, but that would be noticed when the client is registered at the AS (btw. see Appendix D for a list of assumptions what the AS knows about C and RS). > >>> 35. Section 5.7.1 - Why would the RS respond with the cti - given a lack > of >>> text it is not clear when the MAY would be triggered. >> >> It's just a suggestion to the implementer, not really necessary but >> useful in some scenarios (e.g. if the client later wants to delete or >> overwrite the token this could be good to have). > > This is not at all clear or documented. Ok I'll try to clarify. > >>> 36. Section 5.7.1 - Not sure how much information is being leaked by > having >>> different error codes being returned in these situations. May only want > to >>> have one code. >> >> This is a difficult one. One the one hand you are right some information >> is leaked, but on the other hand, withholding that information makes it >> very hard for the client to fix erroneous access tokens. > > Should probably have a security consideration on this. Issue created. > >>> 37. Section 5.7.1 - under what circumstances is the introspection > request >>> not made? >> >> If the RS is not configured to do so. E.g. if it has intermittent >> connectivity and the token is self contained. > > That was assumed. The question is what are you doing in the 3rd to last > paragraph where you say the RS MAY introspect. But does not say anything > about when or why. I would take it as a given that if the token is > self-contained then it would never been done. Why not? Even a self-contained token might be revoked before it expires, which would only work with introspection. > >>> 40. Section 5.7.2 - Another "long running request" might be the case of >>> sending back an ACK for a request followed by a 4.01 because the token >>> expires before the request has finished processing. Re-doing > introspection >>> might also cause this sequence of messages >>> >> >> Do you think it would be useful to give these additional examples? > > I am not really happy with how the paragraph is designed. But no they > probably do not help. Ok I'll try to rephrase then. > >>> 48. Section 6 - Please explain the reasoning behind the last paragraph. > It >>> does not make a great deal of sense to me. >> >> If you issue an access token bound to a symmetric pop-key that is valid >> for a group of RS, then any of these RS that receives the token can use >> to towards the other RS, impersonating the client. >> >> I'll try to clarify the text in the draft (I also noted that the context >> to using a symmetric pop key got lost in the second sentence of that >> paragraph). > > The problem with that statement is that the client is using an asymmetric > key pair here. Right, as I said the context got lost in some rewriting. I'll try to rephrase to make it clearer that only symmetric keys are affected (since in the symmetric case the RS has the symmetric key and thus can perform the PoP itself. > By the way, a quick republish to update email addresses might be desirable > so that the author list does not send back so many bounces. > > I'll do that. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Tue Aug 8 08:19:39 2017 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F3A132478; Tue, 8 Aug 2017 08:19:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150220557112.12290.6678204551376962339@ietfa.amsl.com> Date: Tue, 08 Aug 2017 08:19:31 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-authz-07.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 15:19:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Authentication and Authorization for Constrained Environments (ACE) Authors : Ludwig Seitz Goeran Selander Erik Wahlstroem Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-oauth-authz-07.txt Pages : 64 Date : 2017-08-08 Abstract: This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments. The framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the constraints of IoT devices require it, extensions are added and profiles are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-07 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 16 14:53:08 2017 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5429813273C; Wed, 16 Aug 2017 14:53:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150292038628.15059.17273759217810025693@ietfa.amsl.com> Date: Wed, 16 Aug 2017 14:53:06 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-08.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 21:53:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : CBOR Web Token (CWT) Authors : Michael B. Jones Erik Wahlstr枚m Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-cbor-web-token-08.txt Pages : 24 Date : 2017-08-16 Abstract: CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR) and CBOR Object Signing and Encryption (COSE) is used for added application layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT), but uses CBOR rather than JSON. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-08 https://datatracker.ietf.org/doc/html/draft-ietf-ace-cbor-web-token-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-cbor-web-token-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 16 14:57:57 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF1F132725 for ; Wed, 16 Aug 2017 14:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 dLOGROxcNIYo for ; Wed, 16 Aug 2017 14:57:52 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0115.outbound.protection.outlook.com [104.47.34.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A8F4132710 for ; Wed, 16 Aug 2017 14:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Y5y41zNrnxN9RlNTRtPBioowtjslgj8/9jSsYARfQEI=; b=UdTdpBesHPl3Ig20pGt+sOkAjOEnrh2Il5IMphfB8f24hSY0wWOwhOQXuSOm/Orop2R8KQe+F21QaR5AqhR+SyD2hnoNF0EoG7hncLFZ6qH6LI6Qyzhu1bNe4Hgu4U08LMRpDm5mpyP1Y42WJ2Fs9EgLds26c5sPphjH+R9ntys= Received: from DM5PR21MB0505.namprd21.prod.outlook.com (10.172.91.139) by DM5PR21MB0283.namprd21.prod.outlook.com (10.173.174.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.2; Wed, 16 Aug 2017 21:57:51 +0000 Received: from DM5PR21MB0505.namprd21.prod.outlook.com ([10.172.91.139]) by DM5PR21MB0505.namprd21.prod.outlook.com ([10.172.91.139]) with mapi id 15.01.1385.000; Wed, 16 Aug 2017 21:57:51 +0000 From: Mike Jones To: "ace@ietf.org" CC: Carsten Bormann , Samuel Erdtman Thread-Topic: CBOR Web Token (CWT) specification addressing all known issues Thread-Index: AdMW2X667qMfHzLDSCm3y0rvTJ571w== Date: Wed, 16 Aug 2017 21:57:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-08-16T14:57:50.0141217-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:6::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR21MB0283; 6:vABbtWBIJv9PfRHVfkRdtD5IzZuNS4yLRJP8aDbiZs2zoKwBRuCfjbPL7UurqFFIEbIwZBKdIf50lpK/eXP2HGsJj87EoRuUTpSnYkalVYC0l6IHbBhePqDyraEdBcpJ8mSv2GlRdDLdGxLX+Ugxw+VTxZ4y6wRRzcmaIvx2VrydEEWRzKb+WQl+B0AskaqWaywNbtuvGvLo8gwoT/wUc/H7Sjil9Fa6xA8fnSVfL6oZHzUFj0t18Kgjv+nQgNmvDniHqHduJ9HSClkL09uG/CWQHPmJ8adBcDBp5h45wM5QkZO8cuFNfzSMr2rSr2Qo4PijxjkunmSKEA2EEPkfKQ==; 5:Puo8VW7DD7httJmUOt9j0JHS8CQjkJ7IKB4turO7dZN3zDUu871ZBZk/NUwDkCFw3DwSrSJpBwgFpDz7hZQ3KqUFC3XQnLPdwMnZ4oFqBkgJd0a/V7fxYLWbOX06UsWo2ovUMRUuG4D0bFwHsjkI7Q==; 24:QcsgPzQP62I7NGi+EuNGLuEykHLT4FjtJ3KH562aYctZXf0RY84+d+3DHXwuqdpLI02GQ89faVgVLqLr2SmVCdxspExOhxbtNS7o7VhA4dg=; 7:MeJ6xSUrJyLZrNct2n2NtqjYNA+vOJSGgrb+aJsOKnzURd8Z0wzTUjLgLWAIOpGjPIZ3FLNbz2cdHFqKinwYwK8NrVDb5URsDRezZywhBASozTi7nxqEMEG5t+yzt9GgQlJAeXR1JGAk/GwTMG68fMq+6rJ4zwOJv+lpdjwwnqoMcux3mxWgZ3GCihMputZxvlrPJPXu6t+CWbPQglyODzv+WaVwZ76zLKJ53pTzuSU= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 926d91ef-caed-4d37-ceef-08d4e4f1d725 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603157)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR21MB0283; x-ms-traffictypediagnostic: DM5PR21MB0283: x-exchange-antispam-report-test: UriScan:(31418570063057)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR21MB0283; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR21MB0283; x-forefront-prvs: 0401647B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(209900001)(47760400005)(189002)(199003)(10090500001)(54356999)(6506006)(606006)(4326008)(50986999)(14454004)(2501003)(6916009)(7736002)(5630700001)(101416001)(77096006)(10290500003)(25786009)(54896002)(6306002)(189998001)(8990500004)(72206003)(5005710100001)(478600001)(236005)(33656002)(86362001)(86612001)(53936002)(9686003)(99286003)(54906002)(97736004)(8936002)(966005)(55016002)(74316002)(6436002)(3280700002)(3660700001)(5640700003)(5660300001)(7696004)(2351001)(102836003)(6116002)(790700001)(2900100001)(1730700003)(8676002)(81156014)(81166006)(110136004)(105586002)(106356001)(53376002)(68736007)(2906002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR21MB0283; H:DM5PR21MB0505.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR21MB050589E1FCAB4C08A2C62546F5820DM5PR21MB0505namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2017 21:57:51.1671 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB0283 Archived-At: Subject: [Ace] CBOR Web Token (CWT) specification addressing all known issues X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 21:57:56 -0000 --_000_DM5PR21MB050589E1FCAB4C08A2C62546F5820DM5PR21MB0505namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A new CBOR Web Token (CWT) draft has been published that updates the diagno= stic notation for embedded objects in the examples. Thanks to Samuel Erdtm= an for making these updates. Thanks to Carsten Bormann for reviewing the e= xamples! This addresses all known issues with the specification. I believe that it = is now time to request publication. The specification is available at: * https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-08 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-ace-cbor-web-token-08.html -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1728 and = as @selfissued. --_000_DM5PR21MB050589E1FCAB4C08A2C62546F5820DM5PR21MB0505namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A new CBOR Web Token (CWT) draft has been published = that updates the diagnostic notation for embedded objects in the examples.&= nbsp; Thanks to Samuel Erdtman for making these updates.  Thanks to Ca= rsten Bormann for reviewing the examples!

 

This addresses all known issues with the specificati= on.  I believe that it is now time to request publication.<= /p>

 

The specification is available at:

 

An HTML-formatted version is also available at:=

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     -- Mike

 

P.S.  This notice was also posted at http://self-issued.info/?p=3D1728 and as @selfissued.

--_000_DM5PR21MB050589E1FCAB4C08A2C62546F5820DM5PR21MB0505namp_-- From nobody Thu Aug 17 02:14:28 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C3B13281A for ; Thu, 17 Aug 2017 02:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com 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 X_r0l2Lbuuw2 for ; Thu, 17 Aug 2017 02:14:24 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (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 68D3A13281D for ; Thu, 17 Aug 2017 02:14:22 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id t80so11444563pgb.5 for ; Thu, 17 Aug 2017 02:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=LgmQdfraPoMGYELOHapmgystoHsqp4Z3jMKUUiCm45A=; b=hPo0vXRLWJoOuSrJ4+mjg1mMvmoiTIADtqFtJqjCaO7+K+vjOAgVWdGAp5Nq/HNpTK t/ufq3ODpcdssTmO5sxIq0Djit0wdyrdVRzoFasbMC4nsletVUcz001vFewpVSxMVzRA k9smYg6hbqy+OPPjw4Xjd2b4KIDCbML/plKJtj+FPRTOsmaWs/jib7o9kQjbEPy0tmhQ Ra+PKuBBYdH5n1KcUHnEq19wZFXAUYylW37Q+Zp3X0X3EwU6aHxBreDECAb4bp1Bh33u kVtG1t1bmiOtkvQ+kWMub/h7YB25oNvgYAAoAPZbxq1aNlKfzZIpHla/eAbD+8G4kH+v hvng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LgmQdfraPoMGYELOHapmgystoHsqp4Z3jMKUUiCm45A=; b=FhQ3FQ/vTmdqE44w9ZyBQqnjCImIfsb1ssTa3PkzRRzff5d/pqqHP5J4s/1hJ0xUK8 iV8syT9en23NJyJ0Y0IlaqVEut8h1y5rIDgeOXYRtQH+tOPfkZMJP9i58SDbRJoSDiAt QLt37XQEGloaxug2cT6W0HUPRZCeeJm/+yEVmAlNwccwNkMz0ZNiGScq9hD4WT7VIlTM eS2C3ii12sUdVlw+t7DoZEfdg73W7XH3IjMO1fDlRzbYEc492KczuWDwpaZ+SosMy2Eg sexbaSrBx1y4C/qVhAiMXbyE6iRcZCmC6Ytfzt3RQE3en1fJh6XDesWM66qUM+WfzTfJ JDfw== X-Gm-Message-State: AHYfb5iyqn5AEwV8PXI0IbcfB8gYY2O8k0WL4l4ve4Fgy46Pk+XYbAIb hEOtSSUORnUCNwQS/agCnPeT8+bKRl/+r9uofg== X-Received: by 10.98.198.72 with SMTP id m69mr4571375pfg.188.1502961261600; Thu, 17 Aug 2017 02:14:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.151.67 with HTTP; Thu, 17 Aug 2017 02:14:21 -0700 (PDT) From: Samuel Erdtman Date: Thu, 17 Aug 2017 11:14:21 +0200 Message-ID: To: ace , Mike Jones Content-Type: multipart/alternative; boundary="94eb2c0c3e6c1bf92a0556ef706b" Archived-At: Subject: [Ace] draft-erdtman-ace-rpcc and RFC7521 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 09:14:27 -0000 --94eb2c0c3e6c1bf92a0556ef706b Content-Type: text/plain; charset="UTF-8" Hi Mike and others, During the ACE session at the IETF meeting in Prague I presented draft-erdtman-ace-rpcc and Mike asked how it relates to RFC7521. Here comes a short summary, hope is clarify things. One could probably achieve something similar to what we want by creating a profile of the RFC7521 framework. However I think we would end up with something much more complex than what we need with much more work. The case we want to solve is authentication of the client for interactions with endpoints such as token and introspection (with something more suitable for constrained devices than client_secret i.e. a password). We assume that the client has a key to use for the authentication a Raw-Public-Key (RPK) or a Pre-Shared-Key (PSK) If we look at draft-ietf-oauth-mtls it defines how to do client authentication with a certificate. The functionality for client authentication with certificates are wide spread and well understood, i.e. cheep to implement. In our case we similarly want to piggyback on the availability of RPK and PSK authentication, we do not want to define a new Holder-of-Key schema and put it on top of (D)TLS. RFC7521 does not define a solution for holder of the Holder-of-Key Assertions, so we would have to do that. Based on this we think it would be valuable to have a specification that defines how to use RPK and PSK for client authentication before it becomes defined in the wild (like with certificates). Best regards //Samuel --94eb2c0c3e6c1bf92a0556ef706b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mike and others,

During the ACE = session at the IETF meeting in Prague I presented draft-erdtman-ace-rpcc an= d Mike asked how it relates to RFC7521.

Here comes a short sum= mary, hope is clarify things.

One could probably= achieve something similar to what we want by creating a profile of the RFC= 7521 framework. However I think we would end up with something much more co= mplex than what we need with much more work.

The case we want to sol= ve is authentication of the client for interactions with endpoints such as = token and introspection (with something more suitable for constrained devic= es than client_secret i.e. a password).
We assume that the client has a = key to use for the authentication a Raw-Public-Key (RPK) or a Pre-Shared-Ke= y (PSK)

If we look at draft-ietf-oauth-mtls it defines how to do cli= ent authentication with a certificate. The functionality for client authent= ication with certificates are wide spread and well understood, i.e. cheep t= o implement.
In our case we similarly want to piggyback on the availabil= ity of RPK and PSK authentication, we do not want to define a new Holder-of= -Key schema and put it on top of (D)TLS. RFC7521 does not define a solution= for holder of the Holder-of-Key Assertions, so we would have to do that.
Based on this we think it would be valuable to have a specification t= hat defines how to use RPK and PSK for client authentication before it beco= mes defined in the wild (like with certificates).

Best re= gards
//Samuel
--94eb2c0c3e6c1bf92a0556ef706b-- From nobody Thu Aug 24 02:03:56 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE81A132BC0 for ; Thu, 24 Aug 2017 02:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 h1t7W6lMT1H4 for ; Thu, 24 Aug 2017 02:03:52 -0700 (PDT) Received: from se-out2.mx-wecloud.net (se-out2.mx-wecloud.net [89.221.255.177]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E35E132386 for ; Thu, 24 Aug 2017 02:03:52 -0700 (PDT) Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out2.mx-wecloud.net (Postfix) with ESMTPS id 5DAD7223649 for ; Thu, 24 Aug 2017 09:03:50 +0000 (UTC) Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Thu, 24 Aug 2017 11:03:49 +0200 To: "ace@ietf.org" From: Ludwig Seitz Message-ID: Date: Thu, 24 Aug 2017 11:03:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.116.0.226] X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=S+Gp+MkP c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=IkcTkHD0fZMA:10 a=KeKAF7QvOSUA:10 a=NEAV23lmAAAA:8 a=QLPfpYkryAO4RqcpiSkA:9 a=QEXdDO2ut3YA:10 X-Virus-Scanned: clamav-milter 0.99.2 at MailSecurity X-Virus-Status: Clean X-MailSecurity-Status: 0 X-Scanned-By: WeCloud MailSecurity X-MailSecurity-Score: 0 Archived-At: Subject: [Ace] Question about an issue in draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 09:03:55 -0000 Hello list, I've got a very specific question about an issue raised by Jim Schaad (https://github.com/LudwigSeitz/ace-oauth/issues/98): Currently the draft RECOMMENDS to disallow the client from choosing a specific symmetric key for proof-of-possession (i.e. we want the AS to generate one) when interacting with the /token endpoint at the AS. I cannot remember why we specified it that way, so should we drop that recommendation? /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 From nobody Thu Aug 24 14:28:19 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E301132358 for ; Thu, 24 Aug 2017 14:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 wx7n4UML2rY8 for ; Thu, 24 Aug 2017 14:28:14 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0049.outbound.protection.outlook.com [104.47.40.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96284120720 for ; Thu, 24 Aug 2017 14:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qLiNZON9vItm7Y5j97uWCbSMQzr8uW6e/cjkCoLrn7Q=; b=QQ+k7FGOgi8ieOHo0/WCDn2OZpgwSrOLVFGNlAzutEuCtaqu02CgmLFjafuxUS4/TPuhtNT/459mFx03l36xPjseSrLvsnGl6LxDvZjIVW2ruDHVqJxC8MWPDNAcWiYsVviDO3pEza+nUUpjkmMMgFHyD0cG6DDsvTHvhyAUwNA= Received: from BN6PR06MB3395.namprd06.prod.outlook.com (10.174.235.153) by BN6PR06MB3219.namprd06.prod.outlook.com (10.174.232.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.18; Thu, 24 Aug 2017 21:28:12 +0000 Received: from BN6PR06MB3395.namprd06.prod.outlook.com ([10.174.235.153]) by BN6PR06MB3395.namprd06.prod.outlook.com ([10.174.235.153]) with mapi id 15.01.1385.010; Thu, 24 Aug 2017 21:28:12 +0000 From: Robin Wilton To: "ace@ietf.org" Thread-Topic: Ace Digest, Vol 45, Issue 6 Thread-Index: AQHTHQs3ROaCUGzyzk6ubvQ0WQiRtaKUBayA Date: Thu, 24 Aug 2017 21:28:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=wilton@isoc.org; x-originating-ip: [213.180.180.202] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR06MB3219; 6:DIDTEiP7wUvvONJQAKdUBAG+WU2vSb0A1z7xq2F040V3b8Dq+TEMnkv/S8CPzuwL00LOmLSsyVT+/gqfy0mMZXygouqjAEvOj43zqrtg6QFZH86XH13j3l+uYcKe4choj/aL1Sp5sb2ImV7W4Ey0cS5BcbexxHwiOsP/Xu6Gg340lXY78v17LN5DgO15gSDTRwFgWjV/IuAhuue5t2O17Is62J8FXPWA/8VcFo77S9zyNF8NQrezfa1jQSPpPQ9iy2EL7MDU49oGyy/JwjC54k7fvz96lz+Vbtd448yza/r3lipxUXfgJaMDk//9iAZpq6u31AX86fnkkPQMK1LLkw==; 5:MXNxFt4Czj5SBb6qOZ25xhsI1j0X1enBTauhZibludF+q02R06VcVq8IZ8a9GzbtDfw0mrb5D5m3NBrGRgRZLHD9TvYP07y5twSsXkmPd92/NH8KLlTI8oBJ+/9BA4XHtR8QPwHFablCms4XTlrhhA==; 24:ean0BB0+ZKHwN7oS3TbFSVk8v+6oTc+W60JyLCb1/KOYcBy4x6iIMNEMmxu3zdhfXm6biVtBVevSoDjuHSjJ01la44q+hoMvDLYTFUrZwbA=; 7:NDXLsr5Tmiy1PCf0SmJdcdGSPsWd+mPkhfW/En0oGEeGYfsta7Gl90WtXi3VPBbPbeScmh/67uUleJvNMIKwcRYuu/Aq1tntovceYqUxdNoTcyurcLmd4GjzHJTkhle3O/ezjMHph2viZ1pzgxPcPGwHg5d5Ix86PKfnzsV1IrZFvPFdhriePzOfmipe/vatSOMwBC2xsJVi9UOo4qxl7PbVJa8AYRLmZbn68QxEtAM= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 67cbced4-13c8-4928-a929-08d4eb370649 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(49563074)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR06MB3219; x-ms-traffictypediagnostic: BN6PR06MB3219: x-exchange-antispam-report-test: UriScan:(166708455590820)(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR06MB3219; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR06MB3219; x-forefront-prvs: 04097B7F7F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400002)(18543002)(76094002)(5403001)(27574002)(199003)(189002)(24454002)(10533003)(236005)(2950100002)(50986999)(76176999)(8936002)(54896002)(33656002)(99286003)(6246003)(77096006)(6512007)(106356001)(82746002)(53936002)(86362001)(97736004)(6486002)(5640700003)(2351001)(68736007)(6306002)(189998001)(110136004)(6506006)(99936001)(3660700001)(2906002)(105586002)(54356999)(36756003)(229853002)(25786009)(3280700002)(53546010)(83716003)(2501003)(6116002)(102836003)(966005)(5660300001)(66066001)(3846002)(6436002)(101416001)(6916009)(7736002)(1730700003)(2900100001)(14454004)(81166006)(81156014)(478600001)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR06MB3219; H:BN6PR06MB3395.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_BA205ECF-4FDB-4E51-8F1A-043B52EE02E1"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2017 21:28:12.6051 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB3219 Archived-At: Subject: Re: [Ace] Ace Digest, Vol 45, Issue 6 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 21:28:18 -0000 --Apple-Mail=_BA205ECF-4FDB-4E51-8F1A-043B52EE02E1 Content-Type: multipart/alternative; boundary="Apple-Mail=_757A5190-09C6-485D-881D-E5D9A4BB0E30" --Apple-Mail=_757A5190-09C6-485D-881D-E5D9A4BB0E30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ludwig, It might depend on what you mean by =E2=80=9Cclient=E2=80=9D, and what = you mean by =E2=80=9Cchoose=E2=80=9D. I=E2=80=99m going to assume we don=E2=80=99t want humans involved at any = stage, since they are bad at choosing things. So I=E2=80=99m assuming = =E2=80=9Cclient=E2=80=9D means some element on the device. The original concern may have been about a client device=E2=80=99s = ability to generate reliably random values. The assumption may have been = that the AS would generally have a better chance of accessing sufficient = entropy in support of key generation, and possibly be harder to subvert? Just a thought. R > On 24 Aug 2017, at 20:00, ace-request@ietf.org wrote: >=20 > Send Ace mailing list submissions to > ace@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/ace > or, via email, send a message with subject or body 'help' to > ace-request@ietf.org >=20 > You can reach the person managing the list at > ace-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ace digest..." > Today's Topics: >=20 > 1. Question about an issue in draft-ietf-ace-oauth-authz > (Ludwig Seitz) >=20 > From: Ludwig Seitz > Subject: [Ace] Question about an issue in draft-ietf-ace-oauth-authz > Date: 24 August 2017 at 10:03:49 GMT+1 > To: "ace@ietf.org" >=20 >=20 > Hello list, >=20 > I've got a very specific question about an issue raised by Jim Schaad = (https://github.com/LudwigSeitz/ace-oauth/issues/98): >=20 > Currently the draft RECOMMENDS to disallow the client from choosing a = specific symmetric key for proof-of-possession (i.e. we want the AS to = generate one) when interacting with the /token endpoint at the AS. >=20 > I cannot remember why we specified it that way, so should we drop that = recommendation? >=20 >=20 > /Ludwig >=20 > -- > Ludwig Seitz, PhD > Security Lab, RISE SICS > Phone +46(0)70-349 92 51 >=20 >=20 >=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --Apple-Mail=_757A5190-09C6-485D-881D-E5D9A4BB0E30 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Ludwig,

It might depend on what you mean by =E2=80=9Cclient=E2=80=9D, = and what you mean by =E2=80=9Cchoose=E2=80=9D.

I=E2=80=99m going to assume we don=E2=80=99= t want humans involved at any stage, since they are bad at choosing = things. So I=E2=80=99m assuming =E2=80=9Cclient=E2=80=9D means some = element on the device.
The original concern may = have been about a client device=E2=80=99s ability to generate reliably = random values. The assumption may have been that the AS would generally = have a better chance of accessing sufficient entropy in support of key = generation, and possibly be harder to subvert?

Just a thought.

R

On = 24 Aug 2017, at 20:00, ace-request@ietf.org wrote:

Send Ace mailing = list submissions to
ace@ietf.org

To subscribe or = unsubscribe via the World Wide Web, visit
= https://www.ietf.org/mailman/listinfo/ace
or, via = email, send a message with subject or body 'help' to
= ace-request@ietf.org

You can reach = the person managing the list at
= ace-owner@ietf.org

When replying, = please edit your Subject line so it is more specific
than = "Re: Contents of Ace digest..."
Today's Topics:

  1. Question about an issue in = draft-ietf-ace-oauth-authz
=      (Ludwig Seitz)

From: Ludwig Seitz <ludwig.seitz@ri.se>
Subject: [Ace] Question about an issue in = draft-ietf-ace-oauth-authz
Date: = 24 August 2017 at 10:03:49 = GMT+1
To: = "ace@ietf.org" = <ace@ietf.org>


Hello list,

I've got a very = specific question about an issue raised by Jim Schaad = (https://github.com/LudwigSeitz/ace-oauth/issues/98):

Currently the draft RECOMMENDS to disallow the client from = choosing a specific symmetric key for proof-of-possession (i.e. we want = the AS to generate one) when interacting with the /token endpoint at the = AS.

I cannot remember why we specified it = that way, so should we drop that recommendation?


/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51




_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

= --Apple-Mail=_757A5190-09C6-485D-881D-E5D9A4BB0E30-- --Apple-Mail=_BA205ECF-4FDB-4E51-8F1A-043B52EE02E1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iF4EAREKAAYFAlmfROkACgkQ646Z8yy2wEzmSwD9EvzRfUBS8QSvtXu7m2eyxJqJ ARXqzpHgP0S+mY6fwbwBAJXxDn1LGBmiviSo1XJMN0Jr0KkEGV12YIr5b2LBT7WU =rjRX -----END PGP SIGNATURE----- --Apple-Mail=_BA205ECF-4FDB-4E51-8F1A-043B52EE02E1-- From nobody Mon Aug 28 01:10:56 2017 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBA3132CEA for ; Mon, 28 Aug 2017 01:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com 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 33mLD6Dn5Qq4 for ; Mon, 28 Aug 2017 01:10:52 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 80F45132C23 for ; Mon, 28 Aug 2017 01:10:52 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id k3so14150596pfc.3 for ; Mon, 28 Aug 2017 01:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IkI9ma8ly/n0JeuC52PKbv+sooS0+WWCnMIGn5w4vEw=; b=Lq2QKhnAfhrnpoQ+SPUb5gJI8VHYCFlh4731XCt3pZBbim+ZvS8hteIndQNcD7q4nX XOC3LUbYNkOiMDRYnTCAAw+7RCjSoOOCP2s9ENYVGWP4TeWePoTfxVrE0Sc2KZjab9EL labesGnBfoxGRI1cS/8Tas+YxEyFPKPx4PM9/cUd5+4bZ2M1wWGtUeSkrREJQ5cV0WAZ Hqr30X5HV+Xr8jCwpZr44voM0nE4bxd2Fp1uJEL0GEDs284FB0M+rAb7Wd2mfyZSvEI0 KZQRdXQUTQ/Xypyah98KqmsV4VCDr9Nf/1j66uNTCETrBn/at+YGz4EAU9ztisrUed+9 GLkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IkI9ma8ly/n0JeuC52PKbv+sooS0+WWCnMIGn5w4vEw=; b=Ffoq4GmjfVE8+e0lbBfs5VUgsl8YqPU+NTRI0onIluox4DBLTNztMdEMz5Z50c98xc lqUTowuTmjX21tNS0QYl3ugunpLfcu4hHTr/f55o14GDEzqvuZ84+z75gLHFj5Mlvov1 U/re8ECxJy0AdET5cza+orP6LSOt7VK6Zhz5skbEY1pPdbqTCJt+moKExrXjzEBL3NX0 hxSTzERXsFhp54nmMZ9frrMNzH8au4fez1UMH4CSTUjdXcGzW4/wsgNQCb0n0Or4wKmf OU8mJ9mK/gP4yy+C+TNntaZ9aG7Ip4a9vHK7OGukFu1OEn38B14Cn3tHdEWVfagc8JQx Nx1Q== X-Gm-Message-State: AHYfb5hrNvpuhyOLmRuUQLmLi2L3GD2zZxwSjoAtiYBrE8QoNUA2VUN/ 8Vrv8mzQSwAMgNRdvaffdtfU9pUxB6/pPDFYwg== X-Received: by 10.84.178.162 with SMTP id z31mr7165120plb.301.1503907851619; Mon, 28 Aug 2017 01:10:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.151.67 with HTTP; Mon, 28 Aug 2017 01:10:51 -0700 (PDT) In-Reply-To: References: From: Samuel Erdtman Date: Mon, 28 Aug 2017 10:10:51 +0200 Message-ID: To: Ludwig Seitz Cc: "ace@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c13f1e04565dc0557cbd5c7" Archived-At: Subject: Re: [Ace] Question about an issue in draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 08:10:54 -0000 --94eb2c13f1e04565dc0557cbd5c7 Content-Type: text/plain; charset="UTF-8" I think the recommendation comes form the fact that AS might be better at generating good quality keys as stated by Robin (in another thread). Since it is a recommendation I think it is fine to keep it with some motivating text. Cheers //Samuel On Thu, Aug 24, 2017 at 11:03 AM, Ludwig Seitz wrote: > Hello list, > > I've got a very specific question about an issue raised by Jim Schaad ( > https://github.com/LudwigSeitz/ace-oauth/issues/98): > > Currently the draft RECOMMENDS to disallow the client from choosing a > specific symmetric key for proof-of-possession (i.e. we want the AS to > generate one) when interacting with the /token endpoint at the AS. > > I cannot remember why we specified it that way, so should we drop that > recommendation? > > > /Ludwig > > -- > Ludwig Seitz, PhD > Security Lab, RISE SICS > Phone +46(0)70-349 92 51 > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --94eb2c13f1e04565dc0557cbd5c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think the recommendation comes form the f= act that AS might be better at generating good quality keys as stated by Ro= bin (in another thread).

Since it is a recommendation I think = it is fine to keep it with some motivating text.

Cheers
//Samuel

On Thu, Aug 24, 2017 at 11:03 AM, Ludwig Seitz <ludwig.seitz@ri.se> wrote:
Hello list,

I've got a very specific question about an issue raised by Jim Schaad (= https://github.com/LudwigSeitz/ace-oauth/issu= es/98):

Currently the draft RECOMMENDS to disallow the client from choosing a speci= fic symmetric key for proof-of-possession (i.e. we want the AS to generate = one) when interacting with the /token endpoint at the AS.

I cannot remember why we specified it that way, so should we drop that reco= mmendation?


/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

--94eb2c13f1e04565dc0557cbd5c7--