Malisa Vucinic <[email protected]> wrote: > [the rest of the discussion shifted to [6tisch] joining security start > and end states]
hi, sorry to take so long to reply.... I'm sure you have the same experience
of putting off the most important emails, because they deserve a well thought
out response...
> On 13 May 2015, at 09:43, Michael Richardson <[email protected]>
wrote:
>> So, here, I think you are imagining using some kind of pre-provisioned
>> session-resumption ticket to replace the initial TLS handshake. I
>> think that this is something that one could imagine: the initial TLS
>> handshake is done at the factory, and then, based upon a bearer token,
>> the factories' MASAS (see
>> draft-pritikin-anima-bootstrapping-keyinfra-01) might return that. Is
>> this what you are thinking about?
> So this would be a clean way of doing what I had in mind. I guess an
> obvious concern in this case would be how the initial TLS handshake can
> be done at the factory during mass production in a scalable manner.
I think it depends a lot on what part of the "factory" you are in.
How do factories' load "Manufacturer Installed Certificates" (often called:
MIC. Too confusing a term. We need another TLA for this) now? If my
manufacturing process included a "bed-of-nails" test, then I might do it
at that point via JTAG, otherwise, doing it via JTAG during or after the QA
process seems like the best way to me. Being able to have the device
zerotouch boot the first time might be a major win for the QA process too.
> I was thinking more of something like this:
> Consider the joining node JN_1 which was imprinted with symmetric key
> K_1. MASA keeps track which JNs were imprinted with which keys. MASA
> and all of its nodes use the recommended ticket format from Section 4
> of RFC 5077. Nodes get shipped, deployed.
> 1. JN_1 initiates the join process with the local network, sends its
> IDevID via JA to the JCE.
> 2. JCE asks MASA about JN_1 over https. MASA’s factory sold the nodes
> to the owner of JCE so MASA already knows that JCE is the rightful
> owner of JN_1.
> 3. Then, MASA can generate 48 random bytes to be used as the master
> secret for session between JCE and JN_1. Obviously, MASA is a trusted
> third party. MASA generates the rest of the ticket, using as key_name
> the fingerprint of K_1 and also includes the cipher suite knowing what
> ciphers JN_1 supports, as it manufactured it after all. MASA encrypts
> the ticket using K_1.
> 4. MASA sends to the JCE the encrypted ticket and the plaintext version
> of it (this is what an RFC 5077 client possesses anyways, it does
> however not know K_1).
> 5. JCE can now start the abbreviated handshake with JN_1, including the
> encrypted ticket in ClientHello.
> 6. JN_1 decrypts the ticket using K_1, takes the session state from the
> ticket as normally done in RFC 5077 and verifies that it supports the
> cipher. Then it can continue the abbreviated handshake with JCE.
This would all work well. The 5077/Section 4 format does not include any
information about the end point identifiers, so that's fine. All in all,
it's very Kerberos-like.
> If MASA decides to share K_1 with JCE, JCE can also generate the
> session ticket without any involvement of MASA. All in all, by making
> an assumption on out-of-band exchange of supported ciphers and MASA as
> a trusted third party, I think one could get the DTLS handshake done in
> 4-6, instead of 10-12 packets. Does that make sense and do you think it
> is worth the trouble?
One can go further, and provide K_1 in the form of a QR code with the device.
Or one can provide a bearer token in the QR code, which when provided to the
MASA, convinces the MASA to either hand over K_1, or as you suggested, hand
over the session resumption ticket.
My understanding of Quantum Cryptography is not great; but I what I
understand is that asymmetric algorithms (RSA, ECDSA) are more susectible.
As K_1 would be the key to a symmetric algorithm, it might be less vulnerable
over a long (~20 year) time frame between the device being manufacturered,
being warehoused, and then deployed.
A concern with 1/2 is that the device does not have to prove it (still)
possesses the private part of the IDevID. Instead, K_1 has replaced that.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
