Yep thanks Hannes for the review. That optimizes the solution and removes the
unnecessary hashing of the BSK. Looking at the history, that BSK hashing was
there since a very early version of the draft before we incorporated RFC 9258,
and it never occurred to us to optimize that out once we started using RFC 9258.
We missed the IETF 116 draft cutoff date, but will get draft-03 out after the
meeting.
Thanks,
Owen
-----Original Message-----
From: Emu <emu-boun...@ietf.org> On Behalf Of Dan Harkins
Sent: Wednesday 22 March 2023 19:12
To: Hannes Tschofenig <hannes.tschofe...@gmx.net>; emu <emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-bootstrapped-tls
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/
--
"The object of life is not to be on the side of the majority, but to escape
finding oneself in the ranks of the insane." -- Marcus Aurelius
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
