Thanks Hannes for the detailed review, yes fully agree the language can be cleaned up in the draft,
I'll get a draft-ietf-emu-bootstrapped-tls-03 out before the next meeting. Cheers, Owen -----Original Message----- From: Hannes Tschofenig <hannes.tschofe...@gmx.net> Sent: Tuesday 4 April 2023 15:51 To: Dan Harkins <dhark...@lounge.org>; emu <emu@ietf.org>; Owen Friel (ofriel) <ofr...@cisco.com> Subject: Re: [Emu] draft-ietf-emu-bootstrapped-tls Hi Owen, Hi Dan, thanks for the response and for the clarification. Here is my proposal for improving the wording of the document. First, there is a little bit of inconsistency in the terminology. The Bootstrap Key (BSK) is defined as the public and private key pair. In Section 2 you use the term "Bootstrap Key Pair" to refer to the public and the private key. Here is my proposal: FROM: " 2. Bootstrap Key Pair The mechanism for on-boarding of devices defined in this document relies on bootstrap key pairs. A client device has an associated elliptic curve (EC) bootstrap key pair (BSK). " TO: " 2. Bootstrap Key The mechanism for on-boarding of devices defined in this document relies on the use of an elliptic curve (EC) bootstrap key (BSK). " Later an abbreviation for the BSK is used, namely BSKEY. I changed it for improved readability, as you can see below. Section 2 defines the format of the BSK quite loosely as: " If the BSK public key, specifically the ASN.1 SEQUENCE SubjectPublicKeyInfo from [RFC5280], can be shared in a trustworthy manner with a TLS server, a form of "origin entity authentication" (the step from which all subsequent authentication proceeds) can be obtained. " Later, in Section 3, the encoding is phrased more directly as: " As the BSK is an ASN.1 SEQUENCE SubjectPublicKeyInfo, the client presents a raw public key certificate as specified in Using Raw Public Keys in TLS and DTLS [RFC7250]. " I would therefore suggest to use the following wording in Section 2: FROM: " If the BSK public key, specifically the ASN.1 SEQUENCE SubjectPublicKeyInfo from [RFC5280], can be shared in a trustworthy manner with a TLS server, a form of "origin entity authentication" (the step from which all subsequent authentication proceeds) can be obtained. " TO: " The BSK public key MUST be encoded as the ASN.1 SEQUENCE SubjectPublicKeyInfo from [RFC5280] and if it can be shared in a trustworthy manner with a TLS server, a form of "origin entity authentication" (the step from which all subsequent authentication proceeds) can be obtained. " Regarding "origin entity authentication" I believe the correct wording is actually "entity authentication", if I consult the Handbook of Applied Cryptography (see https://cacr.uwaterloo.ca/hac/about/chap10.pdf). My confusion was mainly about the text in Section 3. Here is some new wording. Note that I omitted the ImportedIdentity, which I consider redundant since the epskid will, in form of the External Identity, become part of the ImportedIdentity of the PSK importer interface. FROM: " 3. Bootstrapping in TLS 1.3 Bootstrapping in TLS 1.3 leverages Certificate-Based Authentication with an External Pre-Shared Key [RFC8773]. The External PSK (EPSK) is derived from the BSK public key, and the EPSK is imported using [RFC9258]. This BSK MUST be from a cryptosystem suitable for doing ECDSA. As the BSK is an ASN.1 SEQUENCE SubjectPublicKeyInfo, the client presents a raw public key certificate as specified in Using Raw Public Keys in TLS and DTLS [RFC7250]. The TLS PSK handshake gives the client proof that the server knows the BSK public key. Certificate based authentication of the client by the server is carried out using the BSK, giving the server proof that the client knows the BSK private key. This satisfies the proof of ownership requirements outlined in Section 1. 3.1. External PSK Derivation An [RFC9258] EPSK is made up of the tuple of (Base Key, External Identity, Hash). The EPSK is derived from the BSK public key using [RFC5869] with the hash algorithm from the ciphersuite: epsk = HKDF-Expand(HKDF-Extract(<>, bskey), "tls13-imported-bsk", L) epskid = HKDF-Expand(HKDF-Extract(<>, bskey), "tls13-bspsk-identity", L) where: - epsk is the EPSK Base Key - epskid is the EPSK External Identity - <> is a NULL salt - bskey is the DER-encoded ASN.1 subjectPublicKeyInfo representation of the BSK public key - L is the length of the digest of the underlying hash algorithm The [RFC9258] ImportedIdentity structure is defined as: struct { opaque external_identity<1...2^16-1>; opaque context<0..2^16-1>; uint16 target_protocol; uint16 target_kdf; } ImportedIdentity; and is created using the following values: external_identity = epskid context = "tls13-bsk" target_protocol = TLS1.3(0x0304) target_kdf = HKDF_SHA256(0x0001) The EPSK and ImportedIdentity are used in the TLS handshake as specified in [RFC9258]. A performance versus storage tradeoff a server can choose is to precompute the identity of every bootstrapped key with every hash algorithm that it uses in TLS and use that to quickly lookup the bootstrap key and generate the PSK. Servers that choose not to employ this optimization will have to do a runtime check with every bootstrap key it holds against the identity the client provides. " TO: " 3. Bootstrapping in TLS 1.3 TLS-POK leverages RFC 8773, which allows a server to authenticate with a combination of a certificate and an external pre-shared key. The external pre-shared key is imported using the PSK importer interface defined in RFC 9258 [RFC9258]. The RFC 9258-defined PSK importer interface takes three inputs: - a so-called base key EPSK, - an External Identity (external_identity), and - an optional context. This specification does not use the context. The base key External PSK (EPSK) and the External Identity (external_identity) used by the RFC 9258-defined PSK importer interface are derived from the BSK public key, as described in Section 3.1. The BSK MUST be from a cryptosystem suitable for doing ECDSA. As the BSK is an ASN.1 SEQUENCE SubjectPublicKeyInfo, the client presents this raw public key to the server, as specified in [RFC7250]. The TLS PSK handshake gives the client proof that the server knows the BSK public key. Certificate based authentication of the client to the server gives the server proof that the client knows the BSK private key. This satisfies the proof of ownership requirements outlined in Section 1. 3.1. Pre-Computation The following derivation steps are performed prior to the use of the PSK importer interface defined in [RFC9258]. As a result, a new base key EPSK (referred as epsk below) and a new external identity (epskid) are derived. The HKDF key derivation functions are defined in [RFC5869] and utilize the hash algorithm from the ciphersuite: epsk = HKDF-Expand(HKDF-Extract(<>, BSK public key), "tls13-imported-bsk", L) epskid = HKDF-Expand(HKDF-Extract(<>, BSK public key), "tls13-bspsk-identity", L) where: - epsk is the EPSK Base Key later used with RFC 9258 - epskid is the EPSK External Identity later used with RFC 9258 - <> is a NULL salt - BSK public key is the DER-encoded ASN.1 subjectPublicKeyInfo representation of the BSK public key - L is the length of the digest of the underlying hash algorithm A performance versus storage tradeoff a server can choose is to precompute the identity of every bootstrapped key with every hash algorithm that it uses in TLS and use that to quickly lookup the bootstrap key and generate the PSK. Servers that choose not to employ this optimization will have to do a runtime check with every bootstrap key it holds against the identity the client provides. " Let me know what you think. Ciao Hannes Am 22.03.2023 um 20:12 schrieb Dan Harkins: > > Hi Hannes, > > Sorry for the delay in responding.... > > On 3/4/23 9:31 AM, Hannes Tschofenig wrote: >> Hi Owen, Hi Dan, > [snip] >> Here is what I have expected to see in the draft given that RFC 9258 >> already defines the derivation of the epskx and the ipskx provided a >> few inputs. Here is what the RFC says: >> >> >> epskx = HKDF-Extract(0, epsk) >> ipskx = HKDF-Expand-Label(epskx, "derived psk", >> Hash(ImportedIdentity), L) > > Yes, that takes the epsk and hashes it with the usage-specific goo > to create a binary blob with its entropy uniformly distributed across > a fixed number of bits. > >> >> IMHO you only need to define >> >> (a) what the base epsk is, and >> >> (b) how to populate the ImportedIdentity structure. >> >> >> Regarding (a): You seem to be setting the base epsk (for the >> HKDF-Extract function above) to the DER-encoded ASN.1 >> subjectPublicKeyInfo representation of the BSK public key (which is >> externally provided, for example by scanning a QR code). >> >> L is 32 since you seem to be mandating the use of HKDF-SHA256 as the >> KDF. > > Yes, you're right. the espk can just be the DER-encoded > ASN.1 subjectPublicKeyInfo representation of the bootstrapping > key-- i.e. bskey. > >> Regarding (b): RFC 9258 defines the ImportedIdentity structure as: >> >> >> struct { >> opaque external_identity<1...2^16-1>; >> opaque context<0..2^16-1>; >> uint16 target_protocol; >> uint16 target_kdf; >> } ImportedIdentity; >> >> >> You populate the ImportedIdentity structure based on the description >> in Section 3.1 as follows: >> >> >> - external_identity = epskid (which seems to be again the DER-encoded >> ASN.1 subjectPublicKeyInfo representation of the BSK public key) >> - context = "tls13-bsk" >> - target_protocol = TLS1.3(0x0304) >> - target_kdf = HKDF_SHA256(0x0001) > > That would not work for the security model we're using which is > based on the Resurrecting Duckling [1]. It is assumed that a server > who has knowledge of the client's bskey is the legitimate "owner" and > is therefore authorized to provision/imprint it. So we can't send the > bskey out naked in the ClientHello, we have to send out something > derived from the bskey. > >> >> With this approach the text at the beginning of Section 3.1 is not >> needed. > > Well, half of what's at the beginning of section 3.1 is still needed. > So what we're gonna do is change it to be: > > epsk = bskey > epskid = HKDF-Expand(HKDF-Extract(<>, bskey), > "tls13-bspsk-identity", L) > > That way the raw DER-encoded ASN.1 will get hashed up by RFC 9258 to > produce the imported key and that key will be identified by something > that is not the raw DER-encoded ASN.1. > > regards, > > Dan. > > [1] https://www.cl.cam.ac.uk/~fms27/duckling/ > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
