Re: [Ace] FW: WGLC comments on draft-ietf-ace-dtls-authorize
Hi Jim, Thanks for comments. On 2019-03-03, 02:44, "Jim Schaad" wrote: I am responding to the review below in regards to the most recent version -06. > -Original Message- > > Section 3.3 - Figure 4 - Where is the 'alg' parameter defined at that level? > > See next comment. > > [GS] alg parameter included > > > Section 3.3 - I am always bothered by the fact that PSK should really be > PSS > > at this point. The secret value is no longer a key and thus does not > > necessarily have a length. There is also a problem of trying to decide > what > > the length of this value would be based on the algorithm. If the client > > offers TLS_PSK_WITH_AES_128_CCM_8 and > TLS_PSK_WITH_AES_256_CCM_8 (I may > > have gotten these wrong but the intent should be understandable) then > what > > length is the PSK supposed to be? > > I think what you are saying is that for the shared secret (k) in the > COSE_Key structure in Fig. 4, the AS needs to tell C what to do with > that shared secret? This was the intention of the alg parameter (which > has a not-so-useful value in this example). Some of what is done here makes sense and some of it makes no sense at all. Happy with the removal of the "alg" parameter in the root map. Happy with the addition of the kid parameter in the COSE_Key object since this is required for doing DTLS w/o sending the token as the identifier. I have no idea what the algorithm is doing here? This is not currently a COSE algorithm, it is a TLS algorithm and thus would not make a great deal of sense. GS: I admit this does not make sense, neither here nor in Fig. 6. The terms of what the PSK length should be would be better covered by a statement along the lines of "When offering and/or accepting a TLS cryptographic suite, the length of the PSK should be at least as long as the symmetric encryption algorithms that are offered." This may already be pointed to in the TLS documents and thus can be referenced to rather than stated explicitly. GS: 1. If the PSK is not uniformly random, the security level is not given by the length. I note in the ACE framework: "The AS generates a random symmetric PoP key." Perhaps we should add 'uniform' to this text? 2. About the proposed text, how about making it into a consideration: "Note that the security level depends both of the length of PSK and the security of the TLS cipher suite and key exchange algorithm." I didn't find any text in TLS that I could reference. When looking at the KDF option that you are providing. I don't understand why you don't just make the KDF function and the length of the secret to be derived as pre-configured properties. There is absolutely nothing that prevents this from being a 141 byte value. GS: I'm not sure exactly what is requested. * HKDF-SHA-256 is mentioned as an example of a KDF, indeed this entire part of the section is an example. Do you want to remove the example using COSE_KDF_Context entirely, or just assume that selected components are preconfigured. * I agree that keyDataLength is restrictive, should we replace that with a consideration on security levels, like the text on PSK above? I am not seeing anything in the security considerations about protecting this secret and what all will be available to an attacker in the event that this secret is leaked. Specifically, it allows for any previously recorded session to be decrypted if the KID is leaked, such as using the KID as the key identifier in the handshake protocol rather than sending across the CWT (assuming that it is encrypted). It will allow for an impersonation attack to occur in the event that the KID for a client in the event that the KID is leaked as the attacker would be able to create the same token that is passed to the client. GS: I agree that a security consideration about protecting the key derivation key is needed. But this is another key shared between AS and RS, wouldn't the security considerations be similar? I don't understand what is the meaning of "KID is leaked". > > > Section 3.3 - Figure 5 - Is this defining a new set of entries for cnf or is > > there a missing layer someplace? > > This is indeed a new set of entries. An internal discussion between the > draft authors led to the opinion that we cannot use a COSE_Key structure > in the cnf structure as this would have different semantics as intended > here. We came to the conclusion that for key derivation, listing the > required fields directly in the cnf structure is the cleanest solution. > > [GS] new layer added, called ACE_Salt. This does not seem to be what was implemented in the current draft. GS: The example in s
Re: [Ace] I-D Action: draft-ietf-ace-coap-est-10.txt
This iteration addresses the recent WGLC feedback from Klaus and Jim. A summary of the issues addressed can be found here https://github.com/SanKumar2015/EST-coaps/issues?utf8=%E2%9C%93&q=is%3Aissue+%22WGLC+review+2%2F27%2F2019%22 It should also cover all other feedback we have received as well. Panos -Original Message- From: Ace On Behalf Of internet-dra...@ietf.org Sent: Friday, March 08, 2019 8:54 AM To: i-d-annou...@ietf.org Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-10.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 : EST over secure CoAP (EST-coaps) Authors : Peter van der Stok Panos Kampanakis Michael C. Richardson Shahid Raza Filename: draft-ietf-ace-coap-est-10.txt Pages : 48 Date: 2019-03-08 Abstract: Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-coap-est-10 https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-10 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 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] I-D Action: draft-ietf-ace-coap-est-10.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 : EST over secure CoAP (EST-coaps) Authors : Peter van der Stok Panos Kampanakis Michael C. Richardson Shahid Raza Filename: draft-ietf-ace-coap-est-10.txt Pages : 48 Date: 2019-03-08 Abstract: Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-coap-est-10 https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-10 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
[Ace] I-D Action: draft-ietf-ace-key-groupcomm-oscore-01.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 : Key Management for OSCORE Groups in ACE Authors : Marco Tiloca Jiye Park Francesca Palombini Filename: draft-ietf-ace-key-groupcomm-oscore-01.txt Pages : 22 Date: 2019-03-08 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-01 https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-oscore-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-key-groupcomm-oscore-01 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
[Ace] I-D Action: draft-ietf-ace-key-groupcomm-01.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 : Key Provisioning for Group Communication using ACE Authors : Francesca Palombini Marco Tiloca Filename: draft-ietf-ace-key-groupcomm-01.txt Pages : 21 Date: 2019-03-08 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-01 https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-key-groupcomm-01 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
