Re: [babel] hmac info model elements

> On Jan 3, 2019, at 6:41 AM, STARK, BARBARA H <bs7652@att.com> wrote:
> 
> I'm looking at what's needed in the info model for HMAC.
> 
> I don't think the Index and PC of the Interface and Neighbor tables need to (or should) be exposed in the info model.
> We had discussed previously that keys should not be readable -- only add and delete keys. In this case, it's good for a non-readable parameter to have a "nickname" or index to reference it with. And it can be useful to know when the key was added. In my experience, these sorts of shared keys are modeled as strings.

I would think the keys are modeled as binary.

> 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.
> Multiple HMAC algorithms are possible. The draft doesn't say how the nodes know which algorithm is being used (if multiple are implemented). The draft does say that only one HMAC is calculated per key. Is it assumed the algorithm choice is configured?
> Should the challenge expiry timer be configurable?
> I've decided to have completely separate HMAC and DTLS objects, because they're very different now that I have detailed designs to work with.
> I'm adding an "operation" datatype to support key and cert manipulation. This is intended to be consistent with YANG "action" datatype.

Is the idea that there is both an input and an output expected for key and cert manipulation? If it is input only, i.e. configuring key and cert., then you would not need an action type. Having said that, in the examples you give below, I expect delete to be an action. 

I am not clear on the ‘check-key’ operation. I would expect that the device is either enabled or disabled to check for HMAC. If enabled, and when a packet is received, the receiver will compute the HMAC (using the key configured for it) on the packet and compare it what is in the packet. If the HMAC compariosn fails, the receiver will drop the packet, and log a count of dropped packets because of mismatch. Why would the management plane need to perform a ‘check-key’ operation?

> 
> 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)

I have the same question as Toke here.

>  security-hmac-algorithm (string: one of the supported HMAC algorithms)

You mean one of the enum values defined above.

Thanks for putting this together.

>  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
>         key-name (string: reference name)
>         key-date (datetime: timestamp when key was added)
>         delete-key (operation)
>         check-key (operation: inputs (string, HMAC of string)) ; the node does its own HMAC computation of the input string and compares this to the input HMAC of string; if the computed and input HMAC are the same the operation succeeds.
> 
> Thoughts?
> Barbara
> 
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel

Mahesh Jethanandani
mjethanandani@gmail.com