Re: [babel] hmac info model elements

[Toke Høiland-Jørgensen <[e-mail]>]

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

>> >> > Toke said: "Bird uses an unencoded string..."
>> >> > <bhs> I'm not sure what "unencoded" means here? But this sounds
>> >> > like maybe the entered string is a "passphrase" / PSK, like what's
>> >> > used for Wi-Fi, which is then used to derive the HMAC key using
>> >> > Unicode encoding?
>> >>
>> >> Nope, no derivation, just the raw ASCII bytes from the string used as
>> >> an HMAC key, zero-padded to the block size. Unless the supplied ASCII
>> >> string is longer than the block size, in which case it is hashed
>> >> first.
>> >
>> > ^^^^^^ ???? So you are saying an overlong key is transmuted into
>> > something else entirely, not truncated?
>> 
>> Yup, that would appear to be the case:
>> 
>> https://gitlab.labs.nic.cz/labs/bird/blob/master/lib/mac.c#L105
>
> I noticed the referenced code mentioned it could be used for OSPF (RFC 5709). So I went to see if RFC 5709 had anything to say about this. And it does:
>    (1) PREPARATION OF KEY
>        In this application, Ko is always L octets long.
>
>        If the Authentication Key (K) is L octets long, then Ko is equal
>        to K.  If the Authentication Key (K) is more than L octets long,
>        then Ko is set to H(K).  If the Authentication Key (K) is less
>        than L octets long, then Ko is set to the Authentication Key (K)
>        with zeros appended to the end of the Authentication Key (K),
>        such that Ko is L octets long.

Ah, nice find! This is exactly what Bird does.

> I'd be fine with this scheme, but think we should probably specify it
> somewhere, like OSPF does.

Agreed. This scheme has the advantage of being simple, and not requiring
another hashing or key derivation algorithm. At the cost of making it
easier to go from the derived key back to the original passphrase. Not
sure if that is a problem that warrants a "proper" key derivation
function?

> I notice OSPF makes no mention of arriving at the Authentication Key
> from a string (or hex). It just assumes its dealing with something
> that has a length measured in octets.
>
> WPA2 limits its passphrase strings to "printable ASCII" characters (32
> - 126). Since OSPF doesn't seem to care how it comes by the Key
> octets, it has no such limit in its spec. I wonder if there are any
> characters that would make one of the babel implementations choke; if
> so we may want to limit what characters can be used if input as ASCII.
> WPA2 does also allow hex PSK, which has no limitation on usable
> values.

I think that we should specify *something*, or we end up with
incompatibilities again. And, well, much as I hate UTF-8-challenged
systems in general, I'm not sure if doing UTF-8 is worth it in this
instance?

-Toke