Re: [Ace] FW: New Version Notification for draft-schaad-cnf-cwt-id-00.txt
> -Original Message- > From: Carsten Bormann > Sent: Monday, October 22, 2018 12:09 PM > To: Jim Schaad > Cc: ace@ietf.org > Subject: Re: [Ace] FW: New Version Notification for draft-schaad-cnf-cwt-id- > 00.txt > > On Oct 22, 2018, at 20:49, Jim Schaad wrote: > > > > I did not like the idea of using key identifiers when linking together CWTs > for authorization purposes. > > Right, they are not very useful as they don’t say anything about the > authorization information that is attached to that key in a specific CWT. > > > As part of that discussion I came up with the idea of using the CWT > identifier instead since that is going to be specific to an AS. > > Sounds better. I would feel even better if I knew what exactly that scope “an > AS” is (it is not represented in the CWT, so there is some misuse potential) Actually this can be placed in a CWT as the issuer field. Jim . > > > This draft is a brief description of the idea and I would like to know how > interested people would be in getting it finished. > > Will read it after the frenzy… > > Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] ACE Framework Review
> -Original Message- > From: Ace On Behalf Of Ludwig Seitz > Sent: Monday, October 22, 2018 6:08 AM > To: ace@ietf.org > Subject: Re: [Ace] ACE Framework Review > > On 10/10/2018 16:24, Stefanie Gerdes wrote: > > Hi, > > > > I looked through the ACE framework document. I think there are some > > open issues that need to be addressed. I will try to summarize the > > main issues below. We provided a rough analysis of the DTLS profile in > > [1], which may also be interesting (many of the issues mentioned there > > were already fixed in the meantime). > > Thank you for your review. Sorry for the long response time. Answers inline. I > also tried to add issues in the issue tracker, but github seems to be > experiencing trouble at the moment. > > /Ludwig > > > Validity of the access token (Token Expiration, Section 5.8.3): There > > seem to be additional requirements here that are currently not > > mentioned. It is not clear how RS determines the freshness of > > introspection messages (and how fresh they are). > > That would be up to the commSec protocol, also it is covered in the security > considerations of RFC 7662. I will add a reference to those considerations in > our security considerations section. This seems to be a bit of an odd requirement to impose on the protocol and not on the RS. The RS should have some type of idea of when it last asked the AS if it was valid and also some idea of when the AS said this was going to expire relative to when it last asked. If the RS asks twice and the AS returns a cached answer that is on the AS and not on the RS. An RS with no sense of time could still implement a counter and ask the AS every nth access to the resource (potentially spreading that over all accesses by anybody). > > > The sequence number approach has the problem that an attacker may > > withhold new tokens from RS. In this case, old tokens are infinitely > > valid. This is particularly damaging because C may have a strong > > interest to withhold new tokens and can easily do so by not relaying > > them to RS. This approach therefore must not be used unless there is > > an additional communication channel between RS and AS that regularly > > informs RS which the most recent sequence number is. > > > This is a best effort approach when the RS has no internal sense of time. Also > the idea was that several client could submit tokens with an ever increasing > unique serial number maintained by the AS. Thus even if one client would > withhold it's newer tokens to keep the old ones from expiring, the other > clients would eventually submit enough new tokens (with higher sequence > numbers) so that the token expires. > > AFAIK the RS with no internal clock at all is a very rare occurrence, thus you > can usually expect some form of wallclock time, and thus implement an > expiration based on "time-since-you-received-this-token". Additionally one could use the clear everything after n accesses to resources. > > Management of the authz-info resource: > > * The authz-info resource is vulnerable to DoS attacks: clients may > > (with or without intention) send large numbers of access tokens to RS. A > > constrained RS may soon run out of memory/storage space if it needs to > > store large numbers of tokens. > > A RS is not expected to store large numbers of tokens. Section 5.8.1 > specifies: > > "The RS MUST be prepared to store at least one access token for future > use." > > Thus the RS can adapt the number of tokens it stores to its constrained > storage resources. This might be a good place to reference the new core draft - too many requests - as a reasonable response for an overloaded server in this case. > > The preferred mitigation should be that the > > authz-info resource is only used for protected communication. This does > > obviously not work for the RPK mode. In the PSK mode, RS should be able > > to decide that it uses the authz-info resource only for protected updates. > > I don't think that will help, since somehow the initial access token > must get to the RS. So even when passing it through the DTLS handshake > (as with PSK in the DTLS profile) the same DoS risk exists. Going the DTLS handshake route might actually make things worse as you are now doing lots of additional process on the server side since you have added all of the DTLS work to the token validation work. > > Validity of the access information: > > It seems that the people who wrote the framework did not consider that > > the keying material is not only provided to RS but also to C. > > How does C determine if the keying material it receives from AS is still > > valid? > > It is valid as long as you don't get a 4.01 (Unauthorized) from the RS. > > > The access token response may comprise an expires_in > > field that contains the validity period of the access token in seconds > > (RFC 6749), but does not specify the validity period of the keying > > material. But even if the validity
Re: [Ace] WGLC for draft-ietf-ace-oauth-params
Here are my WGLC comments: * I am not sure that I understand what the protocol flow is when JAR is being used. Is there a potential case where a JWT would be used as the structure of an OAuth response? If so then is there a problem with defining cnf in section 4.1? * We need to have a OAuth CBOR integer mapping registry - the items in section 6 need to be registered into that registry. * Review - is the 'cnf' parameter in section 3.2 ok with the OAuth group or does it need to be renamed as well? * Check that cnf in 4.1 is going to be ok with draft-ietf-oauth-jwt-introspection-response Jim ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] FW: New Version Notification for draft-schaad-cnf-cwt-id-00.txt
On Oct 22, 2018, at 20:49, Jim Schaad wrote: > > I did not like the idea of using key identifiers when linking together CWTs > for authorization purposes. Right, they are not very useful as they don’t say anything about the authorization information that is attached to that key in a specific CWT. > As part of that discussion I came up with the idea of using the CWT > identifier instead since that is going to be specific to an AS. Sounds better. I would feel even better if I knew what exactly that scope “an AS” is (it is not represented in the CWT, so there is some misuse potential). > This draft is a brief description of the idea and I would like to know how > interested people would be in getting it finished. Will read it after the frenzy… Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-authz
* Section 3.1 - Refresh Token - I don't think that refresh tokens are going to be strings because binary is more efficient. * Section 3.2 - we need to reference TLS 1.3 even if DTLS 1.3 is not yet available. * Description for Figure 6 - Should the example somehow indicate in the message that it is going to be an application/ace+cbor content. Also, I don't know that this is a good example in some ways because this is not a currently documented profile anywhere. * Section 5.6.3 - Should the content type for an error response be application/ace+cbor ? * Section 5.7.1 - Is the content format for a request application/ace+cbor? I assume it is but that is not documented in this section. Section 5.8 - bytes arrays or byte strings? I think CBOR uses the latter * Section 5.8.1 - What is the purpose of creating an identifier for a token? Is this supposed to be used rather than the one from the AS for something like shared secret TLS? Note that this is an unprotected value. * Section 5.8.1 - Given the change in the OSCORE profile, you might want to make this an application/ace+cbor structure as well. * Section 5.8.1 - If the token is "not valid" is the RS required (i.e. MUST) to try introspection before returning a response if the RS does introspection? The text currently says MAY. If this is really MAY then the text should say that the token is always successfully accepted by the RS. * Section 5.8.2 - If the RS is going to do introspection, can it send some type of "Server Busy - try again in xxx" while it does the introspection rather than just doing an ack of the request and possibly waiting a long time? * Section 5.8.3 - third point - I think that the correct text would be "The method does not provide timely expiration, but it makes sure that older tokens will cease to be valid after newer issued tokens are registered with the RS." My problem is that just issuing tokens is not enough as they may be going to a different RS for use. This may also need to have some type of rate limit to issued tokens or making the sequence number be on an RS/audience basis. * Section 6. - The recommendation not to use a shared secret for an audience which is hosted by multiple servers is interesting. This does require that a multiple recipient COSE structure be used and it may be worth calling that out. Also the size of the CWT is going to grow for that. You are also now losing the low-level authentication and thus a signature wrapping is now also needed. * Section 6 - "Developers MUST" para - May want to add that this can also be mitigated to some extent by making sure that keys roll over more frequently. * Section 6 - I am not sure that I agree with the SHOULD NOT in the last paragraph. Think multicast. * Section 6.4 - This also applies to sending back some type of identifier from the RS->C when a token is registered. * Section 8.6.1 - Is pop still this document or is it Mike's document? * Section 8.9 - The description of reference is wrong. * Section 8.12 - some of these should move to the OAuth parameters document? * Section 8.13 - ditto * Appendix A - para "CBOR, COSE, CWT" - Is it really a requirement to use CBOR or is that a recommended? I thought this was part of what Hannes was looking at. * Appendix A - para Client Credentials Grant s/can the/can then/ * Registries - I am wondering if we should think about re-writing a couple of the registries. As things stand it appears that the application/ace+cbor content type is being used in 5 or 6 places. It might make more sense to have a registry for all of the CBOR abbreviations that are being used in a single table and have multiple columns for each of the different places were the content format is being used. This would make it easier to keep everything constant and can make re-use of integer values easier to see. * Comments on protection of CWT/Token: I am wondering if there needs to be any comments on how a CWT is going to be protected. While it is ok to use either a symmetric key or a direct key agreement operation for a single recipient without forcing a signature operation to occur. If the token is going to be targeted a single audience hosted on multiple RSs then a signature operation would be required for the purposes of authentication. * I am not sure where this issue should be raised so I am putting it here. Both of the profiles have as their last security consideration a statement that the use of multiple access tokens is a bad idea. Both of them also devote a large section of text to how to deal with multiple access tokens as does this document. More methods of having multiple access tokens seem to be coming down the path from the OAuth group. This appears to be a distinct contradiction within the set of documents that should be resolved. Jim ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-oscore-profile
* Section 1 - I understand the reasoning behind having the server send back a nonce, although it would be good to have a description someplace about why this is being done. (I would also make it optional as not all RS need to do this.) I do not understand the reasoning behind having the client send a nonce to the server. * Section 3.1 - This is more general than the section, but you should not use the URI path in the text, instead you should be using the name that is in the authz document. * Section 3.2 - Does it really make sense to use 'COSE_Key' to transport the key data? Would a different field name be better? * Section 3.2 - Please provide a justification for the requirement that the ids must be unique over the set of all clients and RS. I can see that the client ids need to be unique on a single RS and RS ids need to be unique for any given client but not the broader statement. * Please add an explicit section on when a RS and a client should discard the security context. * Section 6 - Ok I'll bite - how does not echoing the nonce allow for a man-in-the-middle attack given that the salt and shared secret are still going to be known only to the C and RS and not to the MITM. I can see a DOS attack being made, but that can be done even without this just by causing the response to never be delivered. * Appendix - I am not sure that I think that the EDHOC profile should be in this document as oppose to being in it's own document. The fact that we have not even tried to get this to work in any of the interop tests means that I am less sure that it is well baked. Jim > -Original Message- > From: Ace On Behalf Of Jim Schaad > Sent: Monday, October 8, 2018 2:35 PM > To: ace@ietf.org > Subject: [Ace] WGLC for draft-ietf-ace-oscore-profile > > The chairs believe that the set of documents dealing with the OAuth > framework for constrained environments is nearing the point that we should > be able to advance it to the IESG for publication. We therefore want to > have a full list of issues that need to be dealt with at the Bangkok > meeting. > > This starts a 2 week WGLC for draft-ietf-ace-oscore-profile > > We know that the following issues are outstanding: > > draft-ietf-ace-oscore-profile: > * No current known issues > > > Jim & Roman > > > ___ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] FW: New Version Notification for draft-schaad-cnf-cwt-id-00.txt
I did not like the idea of using key identifiers when linking together CWTs for authorization purposes. As part of that discussion I came up with the idea of using the CWT identifier instead since that is going to be specific to an AS. This draft is a brief description of the idea and I would like to know how interested people would be in getting it finished. Jim -Original Message- From: internet-dra...@ietf.org Sent: Monday, October 22, 2018 11:19 AM To: Jim Schaad Subject: New Version Notification for draft-schaad-cnf-cwt-id-00.txt A new version of I-D, draft-schaad-cnf-cwt-id-00.txt has been successfully submitted by Jim Schaad and posted to the IETF repository. Name: draft-schaad-cnf-cwt-id Revision: 00 Title: Use of a CWT identifier as a Confirmation Method Document date: 2018-10-22 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-schaad-cnf-cwt-id-00.txt Status: https://datatracker.ietf.org/doc/draft-schaad-cnf-cwt-id/ Htmlized: https://tools.ietf.org/html/draft-schaad-cnf-cwt-id-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-schaad-cnf-cwt-id Abstract: TBD 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. The IETF Secretariat ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Updating draft-ietf-ace-actors for Bangkok
Done: Htmlized: https://tools.ietf.org/html/draft-ietf-ace-actors-07 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-actors-07 Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] Fwd: New Version Notification for draft-tiloca-ace-oscoap-joining-05.txt
Hi all, We have just submitted v -05 of the ace-oscoap-joining draft. This version also expands on the rekeying of current group members, and is aligned with the latest ace-key-groupcomm draft submitted earlier today. Best, /Marco Forwarded Message Subject:New Version Notification for draft-tiloca-ace-oscoap-joining-05.txt Date: Mon, 22 Oct 2018 07:04:10 -0700 From: internet-dra...@ietf.org To: Marco Tiloca , Jiye Park , Francesca Palombini A new version of I-D, draft-tiloca-ace-oscoap-joining-05.txt has been successfully submitted by Marco Tiloca and posted to the IETF repository. Name: draft-tiloca-ace-oscoap-joining Revision: 05 Title: Key Management for OSCORE Groups in ACE Document date: 2018-10-22 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/internet-drafts/draft-tiloca-ace-oscoap-joining-05.txt Status: https://datatracker.ietf.org/doc/draft-tiloca-ace-oscoap-joining/ Htmlized: https://tools.ietf.org/html/draft-tiloca-ace-oscoap-joining-05 Htmlized: https://datatracker.ietf.org/doc/html/draft-tiloca-ace-oscoap-joining Diff: https://www.ietf.org/rfcdiff?url2=draft-tiloca-ace-oscoap-joining-05 Abstract: This document describes a method to request and provision keying material in group communication scenarios where communications are based on CoAP and secured with Object Security for Constrained RESTful Environments (OSCORE). The proposed method delegates the authentication and authorization of new client nodes that join an OSCORE group through a Group Manager server. This approach builds on the ACE framework for Authentication and Authorization, and leverages protocol-specific profiles of ACE to achieve communication security, proof-of-possession and server authentication. 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. The IETF Secretariat signature.asc Description: OpenPGP digital signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] I-D Action: draft-ietf-ace-actors-07.txt
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 : An architecture for authorization in constrained environments Authors : Stefanie Gerdes Ludwig Seitz Goeran Selander Carsten Bormann Filename: draft-ietf-ace-actors-07.txt Pages : 31 Date: 2018-10-22 Abstract: Constrained-node networks are networks where some nodes have severe constraints on code size, state memory, processing capabilities, user interface, power and communication bandwidth (RFC 7228). This document provides terminology, and identifies the elements that an architecture needs to address, providing a problem statement, for authentication and authorization in these networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-actors/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-actors-07 https://datatracker.ietf.org/doc/html/draft-ietf-ace-actors-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-actors-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/ ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] ACE Framework Review
On 10/10/2018 16:24, Stefanie Gerdes wrote: Hi, I looked through the ACE framework document. I think there are some open issues that need to be addressed. I will try to summarize the main issues below. We provided a rough analysis of the DTLS profile in [1], which may also be interesting (many of the issues mentioned there were already fixed in the meantime). Thank you for your review. Sorry for the long response time. Answers inline. I also tried to add issues in the issue tracker, but github seems to be experiencing trouble at the moment. /Ludwig The protocol elements of the framework assume that responses are bound to requests in the sense that the receiver of a response can be certain that response actually belongs to a certain request. This requirement should be mentioned, e.g., in the security considerations. Agree. I will add a paragraph. The minimal security requirements for the communication between two communication partners should be listed (C-AS, RS-AS, C-RS, respectively). Which pieces of information do they require prior to the communication? How must the communication be secured? Which keying material do they need to use? The first one I agree with. However the other questions seem more specific to the commSec solution to me, which would put them into the profiles. The framework should point out that all claims that influence the security must stem from claimants that were approved by the respective human being that is responsible for the device, i.e., the requesting party for the client and the resource owner for the AS and RS. Otherwise the solution is not secure. Are there claims that do not influence security? The specification says (section 4): The consent of the resource owner, for giving a client access to a protected resource, can be provided dynamically as in the traditional OAuth flows, or it could be pre-configured by the resource owner as authorization policies at the AS, which the AS evaluates when a token request arrives. The resource owner and the requesting party (i.e., client owner) are not shown in Figure 1. I believe this is what you were looking for, if not please explain what is missing. Validity of the access token (Token Expiration, Section 5.8.3): There seem to be additional requirements here that are currently not mentioned. It is not clear how RS determines the freshness of introspection messages (and how fresh they are). That would be up to the commSec protocol, also it is covered in the security considerations of RFC 7662. I will add a reference to those considerations in our security considerations section. Also, the token introspection approach is particularly vulnerable to DoS attacks since introspection messages must be exchanged to validate every token. This problem applies to regular OAuth introspection as well and is covered in the security considerations of RFC 7662. The sequence number approach has the problem that an attacker may withhold new tokens from RS. In this case, old tokens are infinitely valid. This is particularly damaging because C may have a strong interest to withhold new tokens and can easily do so by not relaying them to RS. This approach therefore must not be used unless there is an additional communication channel between RS and AS that regularly informs RS which the most recent sequence number is. This is a best effort approach when the RS has no internal sense of time. Also the idea was that several client could submit tokens with an ever increasing unique serial number maintained by the AS. Thus even if one client would withhold it's newer tokens to keep the old ones from expiring, the other clients would eventually submit enough new tokens (with higher sequence numbers) so that the token expires. AFAIK the RS with no internal clock at all is a very rare occurrence, thus you can usually expect some form of wallclock time, and thus implement an expiration based on "time-since-you-received-this-token". Authorization of the AS on the RS side: in the ACE framework, RS checks the integrity of the access token (e.g., section 4, section 6, Appendix B: Resource Server). RS must also check that the access token stems from an AS that is authorized by RO to provide the token. If RS accepts tokens from authorization servers that are not approved by RO, the solution is not secure. Introspection messages must also stem from an AS that is approved by RO. This is implicit, if the RS has the key that allows it to verify the integrity of the token that means that it is an AS approved by its RO. I will try to add a sentence to make that more explicit. Access token validation: Section 5.8.1 should point out that RS must check the integrity of the token and validate that it stems from AS that is authorized by RO. We can expand on this phrase I think: "The RS receiving the token MUST verify the validity of the token." Also, it would be helpful if the section
[Ace] FW: New Version Notification for draft-palombini-ace-key-groupcomm-02.txt
Hi all, We have just submitted v-02 of the ace-key-groupcomm draft. This version expands on the re-keying of group members, after nodes join or leave the group. It also tries to clarify the message exchange, giving an high level introduction before every subsection. With this update, we hope to have answered most of the review comments from Jim and Peter (thank you!), we will come back to your reviews and answer to those in detail soon. Thanks, Francesca On 22/10/2018, 14:48, "internet-dra...@ietf.org" wrote: A new version of I-D, draft-palombini-ace-key-groupcomm-02.txt has been successfully submitted by Francesca Palombini and posted to the IETF repository. Name: draft-palombini-ace-key-groupcomm Revision: 02 Title: Key Provisioning for Group Communication using ACE Document date: 2018-10-22 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/internet-drafts/draft-palombini-ace-key-groupcomm-02.txt Status: https://datatracker.ietf.org/doc/draft-palombini-ace-key-groupcomm/ Htmlized: https://tools.ietf.org/html/draft-palombini-ace-key-groupcomm-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-palombini-ace-key-groupcomm Diff: https://www.ietf.org/rfcdiff?url2=draft-palombini-ace-key-groupcomm-02 Abstract: This document defines message formats and procedures for requesting and distributing group keying material using the ACE framework, to protect communications between group members. 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. The IETF Secretariat ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
