[Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06
Benjamin Kaduk <kaduk@mit.edu> Tue, 30 July 2019 15:56 UTC
Return-Path: <kaduk@mit.edu>
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 4595C120187; Tue, 30 Jul 2019 08:56:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.199
X-Spam-Level:
X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[ADVANCE_FEE_2_NEW_FORM=1, BAYES_00=-1.9, FILL_THIS_FORM=0.001, FILL_THIS_FORM_LONG=2, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 JOKfcXMYg2Qs; Tue, 30 Jul 2019 08:56:15 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 B1897120127; Tue, 30 Jul 2019 08:56:11 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6UFu7ex005833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Jul 2019 11:56:09 -0400
Date: Tue, 30 Jul 2019 10:56:06 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: draft-ietf-ace-cwt-proof-of-possession.all@ietf.org
Cc: ace@ietf.org
Message-ID: <20190730155605.GM47715@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/YKRVYQ3DvgFFNyBFul8PCpQXaLw>
Subject: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jul 2019 15:56:17 -0000
We should be consistent across examples about whether the use of CBOR diagnostic notation also requires a disclaimer about "with linebreaks for readability". Section 2 Presenter Party that proves possession of a private key (for asymmetric key cryptography) or secret key (for symmetric key cryptography) to a recipient. nit: it might be worth either capitalizing Recipient to point to the following item more clearly, or specifying "recipient of a CWT" for parallelism with Recipient. (If we do the former we should capitalize Presenter in the following definition. But since we don't use the capitalized terms throughout the text, it wouldn't be my own preference.) Section 3.2 This example key expired in 2013. While the example will "always" be expired for an archival document, it might be worth making it more timely with respect to the publication date. (This holds for basically all time values in the document's examples.) Value 2 for 'kty' should have diagnostic notation /EC2/, not /EC/. [I did not check that the example x and y coordinates are in fact points on P256.] The "COSE_Key" member MAY also be used for a COSE_Key representing a symmetric key, provided that the CWT is encrypted so that the key is not revealed to unintended parties. The means of encrypting a CWT is explained in [RFC8392]. If the CWT is not encrypted, the symmetric key MUST be encrypted as described in Section 3.3. It's hard for me to escape the conclusion that this paragraph needs to be a dedicated section with a bit more discussion about how exactly this usage is performed and encoded. Section 3.3 Is the /HMAC256/ the conventional diagnostic notation for alg value 5 (noting that RFC 8152 calls it both "HMAC256/256" and "HMAC w/ SHA-256")? The following example CWT Claims Set of a CWT (using CBOR diagnostic notation, with linebreaks for readability) illustrates the use of an encrypted symmetric key as the "Encrypted_COSE_Key" member value: { /iss/ 1 : "coaps://server.example.com", /sub/ 2 : "24400320", /aud/ 3: "s6BhdRkqt3", /exp/ 4 : 1311281970, /iat/ 5 : 1311280970, /cnf/ 8 : { /COSE_Encrypt0/ 2 : [ Should this be "/Encrypted_COSE_Key/" and not "/COSE_Enrypt0/"? [I did not validate the COSE_Encrypt0 output] Section 3.4 { /iss/ 1 : "coaps://server.example.com", /aud/ 3 : "coaps://client.example.org", Is it in any way confusing to use client.example.org as opposed to, say, resource.example.org as the audience? /exp/ 4 : 1361398824, /cnf/ 8 : { /kid/ 2 : h'dfd1aa976d8d4575a0fe34b96de2bfad' /kid/ in the 'cnf' map has key 3, not 2. Note that the use of a Key ID to identify a proof-of-possesion key needs to be carefully circumscribed, as described below and in Section 6. Where the Key ID is not a cryptographic value derived from the key or where all of the parties involved are not validating the cryptographic derivation, it is possible to get into situations where the same Key ID is being used for multiple keys. The I don't think this quite covers the needed properties, since we also need some assurance that all parties are interpreting the kid value in the same way. It may be possible to construct such a scenario via an attacker replaying a stolen token or even just inadvertent confusion by some party (quite plausible when we consider scenarios that involve the same key being described by different 'kid' values in messages with different recipients). In particular, if the situation arises where an attacker is able to choose the 'kid' value that will be used, they could deliberately cause a collision with a legitimate value used by some other party. In the world of constrained Internet of Things (IoT) devices, there is frequently a restriction on the size of Key IDs, either because of table constraints or a desire to keep message sizes small. These restrictions are going to protocol dependent. For example, DTLS can nit: "going to be" or maybe even just "are protocol dependent". use a Key ID of any size. However, if the key is being used with COSE encrypted message, then the length of the key needs to be minimized and may have a limit as small as one byte. nit: is this "length of the key" or "length of the key ID"? Note that the value of a Key ID is not always the same for different parties. When sending a COSE encrypted message with a shared key, the Key ID may be different on both sides of the conversation, with the appropriate one being included in the message based on the recipient of the message. While this recipient-dependence is probably unavoidable (as the requisite namespacing would use more space on the wire than is reasonable for many applications), it does merit some security considerations text, noting that such messages are context-dependant and could be misinterpreted if presented in a different context. Audience restrictions, as mentioned in Section 4, provide substantial protection in this regard, but are not necessarily a complete solution. o A recipient can decide not to use a CWT based on a created Key ID if it does not fit the recipient's requirements. I'm not sure I understand the semantics being described here. Are we saying that the issuer might give a presenter a CWT, and by the time the presenter presents the CWT to the recipient, the recipient says "this is no good" and denies the transaction in question, forcing the presenter to go back to the issuer and try again? (How do we know that the issuer would make any different choices the second time around?) o If an issuer is going to use the Key ID confirmation method and is not going to guarantee that serial number uniqueness is going to be preserved, the recipient needs to have that information configured into it so that appropriate actions can be taken. nit: this is the only place in the document that talks about "serial number"s. Do we say what the "appropriate actions" are somewhere else in the document? Section 3.5 Note that another means of proving possession of the key when it is a symmetric key is to encrypt the key to the recipient. The means of obtaining a key for the recipient is likewise protocol specific. While true, there are some subtleties here, namely that the recipient needs some way of knowing that it is the presenter (as opposed to some other party) that has actually performed that encryption. In Kerberos we perform this key confirmation by using the encrypted (session) key for subsequent protocol exchanges, and if the presenter fails to process those exchanges then it is clear the presenter does not actually possess the key. This document does not seem to describe the need for such subsequent confirmation (or, alternately, the consequences of failing to do so.) Section 4 A recipient might not understand the "cnf" claim. Applications that require the proof-of-possession keys communicated with it to be understood and processed MUST ensure that the parts of this specification that they use are implemented. nit(?): I'm not sure I'm parsing this sentence correctly: is "communicated with it" referring to "CWTs that include the 'cnf' claim"? To avoid replay attacks when the proof-of-possession tokens are sent to presenters, a security protocol, which uses mechansims such as nonces or timestamps, has to be utilized. [...] I suspect the RFC Editor will want to reword this sentence to avoid the excessive parentheticals and awkward passive-voice construction. I'll be bold and suggest a more dramatic rewording to preempt that: "Proof of possession only provides the intended security gains when the proof is known to be current and not subject to replay attacks; security protocols using mechanisms such as nonces and timestamps can be used to avoid this risk of replay when sending proof-of-possession tokens to [presenters or recipients]". Note that I am not sure if the original was intended to refer to the transfer of PoP tokens to presenters (as written) or recipients (where risk of replay is more traditionally concerned). from changing any elements conveyed within the CWT payload. Special care has to be applied when carrying symmetric keys inside the CWT since those not only require integrity protection but also confidentiality protection. Do we want to reiterate the common mechanisms for providing confidentiality protection here, or just leave the existing text earlier in the document to cover it? Section 5 This sort of correlation can occur even for subsequent connections between the same two parties if observed by a passive observer (e.g., in the case of a mobile client that changes location). I forget if we have strong enough guarantees on the use of transport-level encryption that would prevent such CWTs from being observed in this fashion. Section 6 ensure correct processing. The recipient needs to be able to use credentials to verify the authenticity, integrity, and potentially the confidentiality of the CWT and its content. This requires the Just from a rhetorical point of view, can you help me understand how credentials would be used to verify the confidentiality of a CWT? It seems like this depends on either (or both of) how the CWT is transmitted or how it is prepared, and I am not sure how the recipient's credentials come into play. recipient to know information about the issuer. Likewise, there needs to be agreement between the issuer and the recipient about the claims being used (which is also true of CWTs in general). We briefly discuss the presenter (in the guise of the subject) in the next paragraph when we talk about key IDs, but are there any other cases where there needs to be coordination with the presenter? Would distributing a symmetric PoP key be considered to fall under this mantle? When an issuer creates a CWT containing a Key ID claim, it needs to make sure that it does not issue another CWT containing the same Key ID with a different content, or for a different subject, within the lifetime of the CWTs, unless intentionally desired. Failure to do so may allow one party to impersonate another party, with the potential to gain additional privileges. Likewise, if PoP keys are used for nit: "same Key ID with a different content" doesn't seem quite right, as the "content" of a Key ID is surely the key-ID value itself. Perhaps "referring to" would be more appropriate. I think we should probably give the reader some indication of what semantics might be attributed to the "intentionally desired" case. It doesn't necessarily need to be a specific example, but we could say what the relevant properties/attributes that might lead to such a situation would be. multiple different kinds of CWTs in an application and the PoP keys are identified by Key IDs, care must be taken to keep the keys for the different kinds of CWTs segregated so that an attacker cannot cause the wrong PoP key to be used by using a valid Key ID for the wrong kind of CWT. Audience restrictions can come into play here, too, right? In that a restricted audience of all the CWTs in turn limits the scope of administration in which this care/segregation needs to be enforced. Section 7 Criteria that should be applied by the Designated Experts include determining whether the proposed registration duplicates existing functionality, determining whether it is likely to be of general applicability or whether it is useful only for a single application, and evaluating the security properties of the item being registered and whether the registration makes sense. I know we've been using (variations of) this text for a while, but it seems to me that it could be more clear than it currently is -- is duplication of functionality grounds for denial of registration? What about general vs. specific applicability? The latter seems more clearly applicable for determining which range from which to allocate, since that has impact on the encoding size. Can the experts insist on updates to the security considerations text of a specification prior to granting approval, or are they limited to denying registration of values with poor security properties or insufficient documentation thereof? Section 7.2.1 Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included. In light of the GDPR and similar regulations (and, as is done in RFC 8602), we may not want to keep all of these, especially postal address, given the lack of a clear need. Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of Is the reference required to be publicly accessible? If not, is it required that a copy be made available to the experts and IANA? Section 7.2.2 o Confirmation Method Name: "Encrypted_COSE_Key" o Confirmation Method Description: Encrypted COSE_Key o JWT Confirmation Method Name: "jwe" o Confirmation Key: 2 o Confirmation Value Type(s): COSE_Encrypt or COSE_Encrypt0 structure (with an optional corresponding COSE_Encrypt or COSE_Encrypt0 tag) Do we want to say something about how, in the case when the tag is omitted, the application protocol specification needs to indicate how to determine which one is in use? Section 8.2 I think [JWT] needs to be normative, as we have a SHOULD-level requirement for the audience restriction procedures it specifies. I just want to check that it's intentional/desired to mix descriptive reference tags (e.g., [JWS]) and RFC-number tags (e.g., [RFC7800]) for the referenced RFCs. Acknowledgements, Authors The datatracker is currently accepting XML v3 format drafts, and the RFC Editor's target cutover date for the end of August is quite soon, so feel free to consider using an XML v3 submission with UTF-8 representations of names not well represented by the ASCII subset.
- [Ace] AD review of draft-ietf-ace-cwt-proof-of-po… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-cwt-proof-o… Jim Schaad
- Re: [Ace] AD review of draft-ietf-ace-cwt-proof-o… Carsten Bormann
- Re: [Ace] AD review of draft-ietf-ace-cwt-proof-o… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-cwt-proof-o… Jim Schaad
- Re: [Ace] AD review of draft-ietf-ace-cwt-proof-o… Ludwig Seitz
- Re: [Ace] AD review of draft-ietf-ace-cwt-proof-o… Carsten Bormann
- Re: [Ace] AD review of draft-ietf-ace-cwt-proof-o… Benjamin Kaduk
- Re: [Ace] AD review of draft-ietf-ace-cwt-proof-o… Ludwig Seitz
- Re: [Ace] AD review of draft-ietf-ace-cwt-proof-o… Ludwig Seitz
- Re: [Ace] AD review of draft-ietf-ace-cwt-proof-o… Jim Schaad
- Re: [Ace] AD review of draft-ietf-ace-cwt-proof-o… Mike Jones
- Re: [Ace] AD review of draft-ietf-ace-cwt-proof-o… Ludwig Seitz