Re: [babel] hmac info model elements

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

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

>> > Appendix A (incremental deployment and key rotation) indicates it should
>> be possible to configure a mode where authenticated packets are sent but all
>> packets are accepted.
> ...
>> > Proposed HMAC model:
>> > add to top level information-obj:
>> > babel-hmac-algorithms (enumerated list of supported HMAC computation
>> algorithms)
>> >
>> > security-hmac-obj
>> >   security-hmac-enable (boolean: enable / disable this instance)
>> >   security-hmac-mode (Boolean: do or don't authenticate received
>> > packets)
>> 
>> How do those two interact?
>
> If an HMAC instance is disabled it's as if this instance doesn't exist. Its keys and hmac-mode values are irrelevant (don't care), and it causes no HMAC to be sent, expected, or checked, and no challenges to be responded to or sent.
> If an HMAC instance is enabled (and there is at least one key to use for signing), then authenticated packets are always sent.
> The hmac-mode toggles whether or not received packets are checked, for
> an enabled HMAC instance.

As I noted I think the setting of whether to check or not should be
per-key; not sure it makes sense to have another global toggle? A global
off switch may be useful, though...

>> >   security-hmac-algorithm (string: one of the supported HMAC algorithms)
>> >   security-interfaces (string list of references to interfaces-obj: the
>> interfaces this instance applies to; if empty, it applies to all interfaces)
>> >   security-add-hmac-key (operation: inputs (reference name, key))
>> >      hmac-key-obj
>> 
>> IMO, we'll need two per-key booleans as well: "use for authentication"
>> and "use for signing". They should be set independent of each other.
>
> OK. We could do this either with 2 Booleans or with a single
> enumeration (sign-only, check-only, sign-and-check, [would an "unused"
> value also be needed?]). Would people prefer Booleans or an
> enumeration? I'm fine either way, but find enumerations easier for
> people to read and understand.

No strong opinion, but I think you are right that an enumeration is
easier to understand. The 'unused' state would be, e.g., for keys that
are retired but not removed entirely (in case they need to be re-enabled
later).

-Toke