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

[Mališa Vučinić <[e-mail]>]

Hello Göran,

Thanks for the review.

See my responses inline.

Mališa

On Wed, Jun 27, 2018 at 3:46 PM Göran Selander <[e-mail]>
wrote:

> 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.
>

(For this discussion, pledge identifier == ID Context):

In oscore-13, Section 3.3 states:

"To ensure unique Sender Keys, the quartet (Master Secret, Master Salt, ID
Context, Sender ID) MUST be unique, i.e. the pair (ID Context, Sender ID)
SHALL be unique in the set of all security contexts using the same Master
Secret and Master Salt."

While we have fixed the Sender ID to 0x00, I believe this OSCORE
requirement is still valid in our case. I am missing the need for requiring
global uniqueness if the ID Context is unique in the "set of all security
contexts using the same Master Secret and Master Salt". What am I missing?

That said, EUI-64 is globally unique and when used as the pledge identifier
/ ID Context, results in unique (Master Secret, Master Salt, ID Context,
Sender ID) no matter if the Master Secret is reused.

My point is that this global uniqueness of EUI-64 comes as a nice-to-have
when provisioning the devices, but that a random string that meets the
requirement cited above is still good enough (and increases privacy by not
sending the vendor-specific EUI-64).

If my understanding on the above is correct, I can clarify the text.


 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.
>

Yes, makes sense to clarify this in security considerations referring to
the OSCORE uniqueness requirements.


>
>
> 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
>

I think that this recommendation should indeed be rephrased. I would like
to avoid referencing any particular method of generating the PSK, I think
that it would be enough to stress that the PSK that ends up being
provisioned to the pledge should meet certain statistical properties (e.g.
unpredictability, entropy). What do you think?


>
>
> 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.)
>

Yes, default replay protection of OSCORE is assumed with the nota bene on
persistency that is already there in Section 8.1.1. I will make this more
apparent.

>
> "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.
>

Yes, of course, will state this explicitly.


> The importance of not reusing the nonce with the same key may be repeated
> in the security considerations.
>

I am not sure if discussing nonce uniqueness with a given key really
belongs to this document. To me, that really belongs to OSCORE. That said,
I think it would be really good to add, as you suggest, a discussion in
security considerations on the uniqueness of OSCORE parameters, referring
to the OSCORE document.


>
>
> "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.
>

Good point, I think this text fits well within the current section on the
OSCORE context.


>
>
> 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.
>

Oops, you are right, apologies, that was left from copy-paste :D


>
> 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.
>

I see your point about the implications and will extend the section, but
for now, I would rather keep the text on Stateless-Proxy self-contained.


> 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.
>

We discussed this on a couple of occasions. CoAP Token does everything we
need from Stateless-Proxy except that in *some cases* it is not long
enough. I would gladly remove any notion of Stateless-Proxy from the draft
as soon as I can point to a document where CoAP token length is increased.

This probably belongs to another thread, but let me bring it up here: The
value that we carry in Stateless-Proxy/Token encodes the value that we
carry as the OSCORE kid context, with some other info.

I am looking for a way to *not* transport OSCORE kid context, but to *use*
OSCORE id context during key derivation and to retrieve the correct OSCORE
context from the Stateless-Proxy/Token value. This would save us 8 bytes.

Looking at oscore-13, this seems to be feasible as in Section 5, there is a
MAY on the transport of kid context, except that when it's carried it
should be set to id_context. Do you see any problem with the solution that
I outlined?

This was brought up in another review regarding message overhead (
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues/19/concerns-about-the-cojp-message-size-the
)


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

Thank you, this text does need to be updated a bit with the changes to the
generic pledge identifier that we introduced.


>
> OLD:
>
> "using the pledge identifier as Master Salt"
>
>
> NEW:
>
> "using the pledge identifier as OSCORE ID Context"
>

Good catch!


>
>
>
> 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.
>


Hmmm... good point. Not sure how to resolve this though..


>
> Section 8.1
>
>
> OLD: "the Master Salt MUST be empty."
>
> NEW: "the Master Salt MUST be the empty byte string."
>

OK


>
> 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.
>
>
>
OK


>
> 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.
>

OK


>
>
> 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>
> ]
>

OK


>
>
> 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.)
>

OK, see above the text on not transporting kid context to save bytes.

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

Thanks!

Göran
>