Re: [babel] babel-hmac: key requirements

["STARK, BARBARA H" <[e-mail]>]

My goal in this discussion is:
1. Getting rid of ambiguity in HMAC key format that is accepted as an input to a babel-hmac implementation on a device.
2. Understand how human beings are expected to interact with getting keys into an implementation, and making sure these expectations are reasonable.
....
> Computation of the key should not happen on the router -- the router
> should be given the computed key, and any secrets used to compute the key
> should not be distributed on the routers.  For example, if the key is obtained
> by hashing a passphrase, then the original passphrase should not be stored
> on the router.  Similarly, if the key is drawn randomly (e.g. by an automated
> key distribution protocol), then the PRNG state should not be exposed to the
> routers.

I'm fine with this, if this is the approach everyone agrees on. But the current draft makes no mention of this expectation, which has resulted in Toke's implementation accepting direct entry of a string it interprets as ASCII and will subsequently hash if the string is longer than the length of the hash (which is inconsistent with the above expectation). I don't blame Toke for doing this -- it seems perfectly reasonable given the lack of specification in the draft and the available tools. I'd like the expectations on the HMAC Key to be easily found by someone scanning the table of contents.

Here is a suggestion:
Insert new 2nd level header below 3 (Data Structures)
## The HMAC Key
The HMAC Key is the exact cryptographic key used with the hash algorithm. How the HMAC Key is provided (e.g., a configuration protocol, a user interface, a separate application that includes a computation algorithm, etc.)  is outside the scope of this specification. The provided HMAC Key MUST NOT be modified in any way prior to use with the hash algorithm. 
 
...

> If you believe that the key derivation procedure should be described, then
> this should happen in a separate draft (that can be used with both Babel-
> HMAC and OSPF static keying), or perhaps in an informative appendix to this
> draft.  In that case, we'd need to consult a cryptographer in order to select a
> safe KDF.

No, I don't think that's needed, and I don't think we have anything to say about OSPF static keying. What I do think is needed is a lack of ambiguity around what the "HMAC Key" is and a statement that no modification of the provided HMAC Key is permitted. If that's the approach being taken.

Barbara