Re: [Ace] edhoc section 4.3.2

[Michael Richardson]

Göran Selander  wrote:
> In issue 16 it was requested to allow multiple uses of ephemeral keys
> and it was added in the security considerations. I think it makes sense
> to mandate the verification of nonce uniqueness during reuse of
> ephemeral keys and have reopened issue 16:


> https://github.com/EricssonResearch/EDHOC/issues/16

Good, this lets a node trade off storage and compute power.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] edhoc section 4.3.2

[Göran Selander]

Hi Michael,

Please see the latest version of EDHOC:
https://ericssonresearch.github.io/EDHOC/

The draft has gone through a number of reviews and is in many ways
rewritten. We will submit a new version next week. Inline:

On 2017-02-24 03:08, "Michael Richardson"  wrote:

>
>It says:
>>4.3.2.  message_1 -> V
>>
>>   Party V processes the received message_1 as follows:
>>
>>   o  Party V SHALL verify that the nonce has not been received before.
>> If the verification fails, the message MUST be discarded.
>> Otherwise, Party V SHALL store a representation of the nonce
>> for future verifications.
>
>Please clarify "has not been received before". Ever? Or within some
>interval?  In IKE, we care about the nonces not being reused during the
>time
>that the node continues to use the same keypair at its end. (In DH,
>this means the same y value for g^y). But, you specify a fresh keypair
>each
>time.

Verification of nonces is now optional (e.g. section 4.2.3). Nonces are
not allowed to be reused but it is noted that replay of message_1 cannot
be detected unless unless previous nonces are stored (see security
considerations).


In issue 16 it was requested to allow multiple uses of ephemeral keys and
it was added in the security considerations. I think it makes sense to
mandate the verification of nonce uniqueness during reuse of ephemeral
keys and have reopened issue 16:


https://github.com/EricssonResearch/EDHOC/issues/16


>
>Can two nodes U1 and U2 both use the same nonce (by random chance!)
>Or must it be unique among all peers?
>
>Storing such nonces is impossible for a constrained node...
>Even a non-constained node V won't be able to store many nonces received,
>once you count adding indexes to search for the list efficiently.

Agree.

Göran








___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace