Subject: [babel] hmac info model elements

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 3 Jan 2019 14:41:09 +0000

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

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 03 Jan 2019 19:29:16 +0100

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

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

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

>          key-date (datetime: timestamp when key was added)

Please make key-date optional.

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 03 Jan 2019 21:58:25 +0100

>   security-hmac-mode (Boolean: do or don't authenticate received

How do those two interact?

>   security-add-hmac-key (operation: inputs (reference name, key))  

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.

-Toke

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 3 Jan 2019 13:25:35 -0800

> On Jan 3, 2019, at 6:41 AM, STARK, BARBARA H <[email-masked]> wrote:
> 

I would think the keys are modeled as binary.

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

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

> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

Mahesh Jethanandani
[email-masked]

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 4 Jan 2019 16:22:29 +0000

> It's a local configuration issue, and therefore out of scope for the protocol
> description.
>

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. 😊

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

> 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).
 
> Please make key-date optional.

Yes, I agree. 
Barbara

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 4 Jan 2019 19:51:39 +0000

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

> interfaces this instance applies to; if empty, it applies to all interfaces)

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.
Barbara

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 4 Jan 2019 19:54:32 +0000

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

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?
 
> 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?
> > 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.
 
> I have the same question as Toke here.

OK. I've sent a reply to Toke's email.

Yes.
 
> >         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
> >

---

From: Dave Taht <[email-masked]>
Date: Fri, 4 Jan 2019 12:02:30 -0800

> 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 hu…

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) or (
http://docs.ros.org/diamondback/api/wpa_supplicant/html/base64_8c.html
) for all else.

-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 04 Jan 2019 21:34:45 +0100

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

> 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

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 04 Jan 2019 21:38:33 +0100

"STARK, BARBARA H" <[email-masked]> writes:

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

Bird uses an unencoded string...

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 04 Jan 2019 23:02:46 +0100

>> In my experience, these sorts of shared keys are modeled as strings.

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

There's a third model -- locally generated from a passphrase on the local
host (e.g. using a PSK).

-- Juliusz

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 4 Jan 2019 15:08:31 -0800

> On Jan 4, 2019, at 12:02 PM, Dave Taht <[email-masked]> wrote:
> 
> On Fri, Jan 4, 2019 at 11:54 AM STARK, BARBARA H <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> (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.

>> [email-masked] <mailto:[email-masked]>
>> 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: 1-831-205-9740

Mahesh Jethanandani
[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 4 Jan 2019 15:12:53 -0800

> On Jan 4, 2019, at 3:08 PM, Mahesh Jethanandani <[email-masked]> wrote:
> 
> 
> 
>> On Jan 4, 2019, at 12:02 PM, Dave Taht <[email-masked] <mailto:[email-masked]>> wrote:
>> 

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.";
                 }
               }
             }

>>>> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> 
> 
> 

Mahesh Jethanandani
[email-masked]

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 7 Jan 2019 16:23:04 +0000

Coming back to modeling of HMAC keys (and PSKs) after the weekend...

Juliusz said: "There's a third model -- locally generated from a passphrase on the local host (e.g. using a PSK)." 
<bhs> If I understand this correctly, this is actually what I thought we would be doing (though I would use the word "derived" instead of "generated", because "derive" to me implies the same result will always be had at the end of the derivation, while "generated" may have a random aspect). Example: WPA (for Wi-Fi, using SHA-1) uses an alphanumeric passphrase / pre-shared key (PSK) (and SSID) that are provided to Wi-Fi endpoints, somehow (various possible methods of providing). The PSK (and SSID) are first converted to Unicode representation of the alphanumeric characters, before being used to derive the HMAC-SHA1 key using the RFC 2898 PBKDF2 pseudorandom function. This is the model I've been envisioning would be used for babel (except we have SHA-256 instead of SHA-1). 

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?

Dave wants hex or base64.
<bhs> By this, I'm thinking Dave is actually talking about the HMAC key itself (exactly 256 bits)?

Mahesh said: "RFC8177, YANG Key Chain, models keys as either string or hexadecimal".
<bhs> Now that I've been reading up on HMAC keys -- I think if we're modeling the actual key, it should be hex. If a PSK, then string.

If I'm understanding all of this, I think (?) I'm agreeing with Juliusz and that the info model should support supplying a string PSK, and it should be called something like "hmac-psk" so it's not confused with the HMAC key. We could also allow for supplying the actual HMAC key, which I think should be hex. I'm fine with or without supporting the actual HMAC key in the info model. I think PSK is important.
Barbara

> -----Original Message-----
> From: Juliusz Chroboczek <[email-masked]>
> Sent: Friday, January 04, 2019 5:03 PM
> To: STARK, BARBARA H <[email-masked]>
> Cc: 'Mahesh Jethanandani' <[email-masked]>; Babel at IETF
> <[email-masked]>
> Subject: Re: [babel] hmac info model elements
> 
> There's a third model -- locally generated from a passphrase on the local host
> (e.g. using a PSK).
> 
> -- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 07 Jan 2019 17:35:36 +0100

"STARK, BARBARA H" <[email-masked]> writes:

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

However, looking at the code again, this is actually controlled by the
protocol, so if we were to specify something different for Babel, that
would be doable as well... And I think agreeing on a mechanism would
probably be a good idea to ensure interoperability.

-Toke

---

From: Dave Taht <[email-masked]>
Date: Mon, 7 Jan 2019 09:06:16 -0800

> string is longer than the block size, in which case it is hashed

^^^^^^ ???? So you are saying an overlong key is transmuted into
something else entirely, not truncated?

> probably be a good idea to ensure interoperability.

yea!

Maybe I'm old, but the WEP failure vs the WPA success came down in
part to the human readability of the key.

(I note that I'm actually unhappy we ended up with encrypted wifi
itself, as it's bad for spectrum management etc, but not today)

-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 07 Jan 2019 20:11:39 +0100

> 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

-Toke

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 7 Jan 2019 22:18:09 +0000

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

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.

I'd be fine with this scheme, but think we should probably specify it somewhere, like OSPF does. 
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.
Barbara

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 08 Jan 2019 09:32:53 +0100

>        such that Ko is L octets long.

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

> 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