Re: [babel] hmac info model elements

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

> > Multiple HMAC algorithms are possible. The draft doesn't say how the
> > nodes know which algorithm is being used (if multiple are implemented).
> 
> It's a local configuration issue, and therefore out of scope for the protocol
> description.
>
> > The draft does say that only one HMAC is calculated per key. Is it
> > assumed the algorithm choice is configured?
> 
> Yes.

Good -- I wasn't suggesting it should be in the protocol description. I was just reading through the draft to find things that might need to be configured and therefore supported in the info model. It sounds like we agree HMAC algorithm selection is such a thing. 😊

> > Should the challenge expiry timer be configurable?
> 
> No.  It's an implementation detail, and any value between a few seconds and
> a few minutes will do.

Good. I didn't really think so either but wanted to check.

> > security-hmac-obj
> 
> [...]
> 
> >   security-interfaces (string list of references to interfaces-obj: the
> >   interfaces this instance applies to; if empty, it applies to all
> >   interfaces)
> 
> Hmm... that got me confused for a while, but I see what you're doing here.

Good? My goal is to make it easy for a simple implementation to just support HMAC either enabled (on all interfaces) or disabled, with a single set of keys; but to allow for implementations where HMAC can be enabled/disabled per interface (or set of interfaces) and with different keys per interface (set). Even with the more complex implementation, it should still be easy to enable HMAC across all interfaces with a single set of keys. The simple implementation wouldn't even need to implement the security-interfaces parameter -- where absence of the parameter means the same thing as an empty string (i.e., this instance of the HMAC security object applies to all interfaces).
 
> >   security-add-hmac-key (operation: inputs (reference name, key))
> >      hmac-key-obj
> >          key-name (string: reference name)
> >          key-date (datetime: timestamp when key was added)
> 
> Please make key-date optional.

Yes, I agree. 
Barbara
 
> -- Juliusz