Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05

[Yaron Sheffer <[e-mail]>]

Hi Manav,

On 05/20/2014 01:35 PM, Bhatia, Manav (Manav) wrote:
> Hi Yaron,
>
[...]

>>>>
>>>> • 2.2: the various time values included in the SA essentially
>> require
>>>> (rough) time synchronization between the nodes. If this is the case,
>>>> time values could have been used for replay protection, which would
>>>> have
>>>> been much simpler to implement than the 64-bit sequence number which
>>>> needs to persist across reboots.
>>>
>>> The various timers are only associated if somebody wants to rollover
>> the keys. The granularity of these timers can be coarse (implementation
>> specific) and will not be secure enough to use for anti replay
>> protection.
>>
>> Note that the timer values are optional (the draft says they can be
>> left
>> "unspecified"), but the draft doesn't say what value should be in the
>> field if the values are to be omitted. I *guess* it should be "0",
>> please clarify it.
>
> We have the following text in the draft:
>
>     In order to achieve smooth key transition, KeyStartAccept SHOULD be
>     less than KeyStartGenerate and KeyStopGenerate SHOULD be less than
>     KeyStopAccept.  If KeyStartGenerate or KeyStartAccept are left
>     unspecified, the time will default to 0 and the key will be used
>     immediately.  If KeyStopGenerate or KeyStopAccept are left
>     unspecified, the time will default to infinity and the key's lifetime
>     will be infinite.
>
> Can you suggest what else needs to be added to make it clearer?

I suggest to add: "Any unspecified values are encoded as zero."
>
>>
[...]
>>
>>>> • 7: 128-bit keys are OK (or overkill) for some algorithms, but too
>>>> short for others. In general, the recommended key length is not
>>>> constant. It depends on the algorithm.
>>>
>>> This needs to be punched on each router console. For an internal
>> network, do you think 128 bit isnt good enough?
>>
>> Personally, I think 128 bits are great :-) Seriously, if people are
>> using HMAC-SHA-512 then 128 is not appropriate. You can argue that you
>> don't need more than 128 bits of entropy, but then I would suggest to
>> remove SHA-512 from the draft. The general point is that different
>> algorithms require different key lengths.
>
> I think you missed the text in Sec 5.1 which says:
>
>     The LDP Cryptographic Protocol ID is appended to the Authentication
>     Key (K) yielding a Protocol Specific Authentication Key (Ks).  In
>     this application, Ko is always L octets long.  While [RFC2104]
>     supports a key that is up to B octets long, this application uses L
>     as the Ks length consistent with [RFC4822], [RFC5310], [RFC5709] and
>     [RFC7166].
>
> In case of HMAC-SHA-512 the key size would be 512 bits.
>
> We never restrict the key size to 128.
>

I was referring to the following text, which I still think is misguided: 
"Deployments SHOULD use sufficiently long and random values for the 
Authentication Key so that guessing and other cryptographic attacks on 
the key are not feasible in their environments.  Furthermore, it is 
RECOMMENDED that Authentication Keys incorporate at least 128 
pseudo-random bits to minimize the risk of such attacks."

Crypto keys should have random bits amounting to their full length, 
rather than just a 128-bit subset of the key.

>>
>>>>
[...]

>
> Cheers, Manav
>