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
