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
