Re: [babel] hmac info model elements

[Mahesh Jethanandani <[e-mail]>]

> On Jan 4, 2019, at 3:08 PM, Mahesh Jethanandani <[e-mail]> wrote:
> 
> 
> 
>> On Jan 4, 2019, at 12:02 PM, Dave Taht <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> On Fri, Jan 4, 2019 at 11:54 AM STARK, BARBARA H <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>>>> 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.
>>> 
>>> That depends on how we generally expect the keys to be generated. If we think they'll be randomly generated by a centralized machine, then binary makes sense. If we think they'll be created by a human being who will input them through a keyboard, then string makes sense. I was thinking the latter would be more common. I'm curious what others think?
>> 
>> What I wanted was a representation that was standard and unambiguous.
>> 0xdeadbeef for a hex representation, base64
>> (https://tools.ietf.org/html/rfc4648#page-7 <https://tools.ietf.org/html/rfc4648#page-7>) or (
>> http://docs.ros.org/diamondback/api/wpa_supplicant/html/base64_8c.html <http://docs.ros.org/diamondback/api/wpa_supplicant/html/base64_8c.html>
>> ) for all else.
> 
> YANG does not have a data type for base64. It uses base64 as an encoding, e.g. binary data is encoded as base64 for transmission over the wire. But you do not represent/configure the data using base64 in YANG. The choices would be string or binary.

Sorry. I should have added that RFC8177, YANG Key Chain, models keys as either string or hexadecimal (not binary).

             choice key-string-style {
               description
                 "Key string styles";
                case keystring {
                  leaf keystring {
                   type string;
                   description
                     "Key string in ASCII format.";
                 }
               }
               case hexadecimal {
                 if-feature "hex-key-string";
                 leaf hexadecimal-string {
                   type yang:hex-string;
                   description
                     "Key in hexadecimal string format.  When compared
                      to ASCII, specification in hexadecimal affords
                      greater key entropy with the same number of
                      internal key-string octets.  Additionally, it
                      discourages usage of well-known words or
                      numbers.";
                 }
               }
             }

> 
>>>>> 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.
>>> 
>>> The only output needed is the result of the operation (success or failure).
>>> As I think about why BBF went with an operation for adding/deleting a X.509 cert, I realize it had to do with things related to its being an X.509 cert and not a "credential". So I think I agree with you here that for an HMAC key, the regular model manipulation mechanisms are fine (including for delete) and the key can just be noted as non-readable.
>>> 
>>>> 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?
>>> 
>>> We're making the key non-readable, once written. The check-key operation gives the router something to hash, and a hash of that something that you've created on your end (using what you think the key is), and asks the router if the hash it creates is the same as the hash you created. If yes, then you know (1) the key is what you think it is, and (2) the hash is being computed using the algorithm you think it is using. If the HMAC comparison is consistently failing, this can be a useful troubleshooting mechanism (especially when setting up a new network using routers with different implementations). Just knowing the packet is getting dropped doesn't tell you much. There are many things that could cause droppage.
>>> But this would be optional to support. And I won't insist on it if others don't think it's a good idea.
>>> It's similar to a fingerprint comparison done for an X.509 certificate.
>>> 
>>>>> 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.
>>> 
>>> OK. I've sent a reply to Toke's email.
>>> 
>>>>> security-hmac-algorithm (string: one of the supported HMAC
>>>>> algorithms)
>>>> 
>>>> You mean one of the enum values defined above.
>>> 
>>> Yes.
>>> 
>>>> 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
>>>>> [e-mail] <mailto:[e-mail]>
>>>> 
>>>> Mahesh Jethanandani
>>>> [e-mail] <mailto:[e-mail]>
>>> _______________________________________________
>>> babel mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/babel <https://www.ietf.org/mailman/listinfo/babel>
>> 
>> 
>> 
>> -- 
>> 
>> Dave Täht
>> CTO, TekLibre, LLC
>> http://www.teklibre.com <http://www.teklibre.com/>
>> Tel: [phone]
> 
> Mahesh Jethanandani
> [e-mail] <mailto:[e-mail]>
> 
> 
> 

Mahesh Jethanandani
[e-mail]