Subject: Re: [6tisch] WGLC on the “Minimal Security Framework for 6TiSCH” document

From: Göran Selander <[email-masked]>
Date: Wed, 27 Jun 2018 13:46:07 +0000

Dear WG, Pascal, Thomas,

I have reviewed draft-ietf-6tisch-minimal-security-06 and have the following feedback:

Section 3

"pledge identifier"

The assumptions and application of OSCORE made in this draft requires that the pledge identifier is globally unique. Although the first sentence states that the pledge identifier uniquely identifies the pledge, there is no normative text in this section and it may not be understood that uniqueness is a requirement. The last sentence says that the identifier may be "e.g. a random string", without any further details. Please include all relevant requirements on the pledge identifier in this section so readers can get the complete picture, make a reference to a security consideration providing the explanation (see below), and apply the requirements to the example with random strings.

Section 4

"It is RECOMMENDED to generate the PSK with a cryptographically secure pseudorandom number generator."

There are a number things to consider when generating random numbers. Consider replace this specific recommendation about one such component with a reference to some existing specification containing recommendations, for example NIST SP800-90A Rev 1 (2015): https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf

Section 8.1

There is no mention of replay protection mechanism. Is the default replay window type and size assumed? (Other default values of OSCORE security context are explicitly stated in the draft.)

"Failure to comply will break the confidentiality property of the Authenticated Encryption with Associated Data (AEAD) algorithm due to the nonce reuse."

Nonce reuse also causes loss of authenticity and integrity, i.e.essentially breaks the security guarantees. The importance of not reusing the nonce with the same key may be repeated in the security considerations.

"This OSCORE security context is used for initial joining of the (6LBR) pledge, where the (6LBR) pledge acts as a CoAP client, as well as for any later parameter updates, where the JRC acts as a CoAP client and the joined node as a CoAP server, as discussed in Section 9.2<https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-06#section-9.2>.  A (6LBR) pledge is expected to have exactly one OSCORE security context with the JRC."

This is correct, not specific to this application of OSCORE, but may be good for explaining how it works. In the spirit of explaining OSCORE and not specific to this application, you could emphasize that the same Sender Context is always used when sending, independently of if the node is CoAP client or CoAP server, so that role switching between client and server must not change the Sender / Recipient Context in a given endpoint. This may be added here, in the security considerations section, or in both.

Section 9

Figure 2: remove "Message Framing" from the figure, since that refers to reliable transport and the figure indicates UDP is the underlying layer.

Section 10

Use the term "Class U" in the description of  OSCORE processing of the Stateless-Proxy CoAP Option. Since it is class U it is recommended to describe implications of an adversary eavesdropping or manipulating the value of the option, e.g. in the security considerations.

Maybe this has already been discussed: Would it be possible/desirable to use the Token instead of this new option? The allowed size of Tokens would need to be enlarged but besides that, are there any other limitations?  The Tokens would be unique by construction and the overhead would be reduced.

Section 11

Explain how the requirement of unique pledge identifier follows from the assumptions and application of OSCORE in this draft.

OLD:

"using the pledge identifier as Master Salt"

NEW:

"using the pledge identifier as OSCORE ID Context"

NITS:

General:

The term "role" is used in three different ways: whether node is pledge, JP or JRC; whether pledge is 6LBR or not; and whether (6LBR) pledge is CoAP client or CoAP server. Not necessarily an issue, but maybe worth reconsidering.

Section 8.1

OLD: "the Master Salt MUST be empty."

NEW: "the Master Salt MUST be the empty byte string."

OLD:

the ID of the pledge MUST be set to the byte string 0x00.  This

identifier is used as the OSCORE Sender ID in the security context

derivation, as the pledge initially plays the role of a CoAP client.

NEW:

the ID of the pledge MUST be set to the byte string 0x00.  This

identifier is used as the OSCORE Sender ID of the pledge in the security context derivation, as the pledge initially plays the role of a CoAP client.

OLD:

the ID of the JRC MUST be set to the byte string 0x4a5243 ("JRC" in ASCII). This identifier is used as the OSCORE Recipient ID in the security context derivation, as the JRC initially plays the role of a CoAP server.

NEW:

the ID of the JRC MUST be set to the byte string 0x4a5243 ("JRC" in ASCII). This identifier is used as the OSCORE Recipient ID of the pledge in the security context derivation, as the JRC initially plays the role of a CoAP server.

Section 8.1.1

OLD:

detailed in Section 6.5.1 of [I-D.ietf-core-object-security<https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-06#ref-I-D.ietf-core-object-security>]

NEW:

detailed in Section 7.5.1 of [I-D.ietf-core-object-security<https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-06#ref-I-D.ietf-core-object-security>]

Section 9.1.1

"The OSCORE security context used is the one derived in Section 8.1<https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-06#section-8.1>. The OSCORE kid context is set to the ID context, which in turn is set to the pledge identifier. The OSCORE kid context allows the JRC to retrieve the security context for a given pledge."

Aestethical remark: The middle sentence is redundant. The purpose of the COSE parameter 'kid context' is used to transport the ID Context, and Section 8.1 specifies that  "the ID Context MUST be set to the pledge identifier”. (You may want to keep it for clarification though.)

Overall I found the draft very well written and was overall easy to follow even not knowing much of the details of 6tisch.

Göran

From: 6tisch <[email-masked]<mailto:[email-masked]>> on behalf of "Pascal Thubert (pthubert)" <pthubert=[email-masked]<mailto:pthubert=[email-masked]>>
Date: Friday, 15 June 2018 at 16:50
To: "[email-masked]<mailto:[email-masked]>'" <[email-masked]<mailto:[email-masked]>>
Cc: Suresh Krishnan <[email-masked]<mailto:[email-masked]>>
Subject: [6tisch] WGLC on the “Minimal Security Framework for 6TiSCH” document

Dear WG:

As discussed during the last interim, we are starting a WGLC on the “Minimal Security Framework for 6TiSCH” document:

https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/

This is  key building block for 6TiSCH, so please, DO review the document and DO provide your comments and remarks if you see any issues.

This WGLC will end in 2 weeks, on June 29th, 2018, 21:00 CEST.

All the Best,
Pascal and Thomas