Re: [babel] Roman Danyliw's No Objection on draft-ietf-babel-information-model-11: (with COMMENT)

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

Hi Roman,
Thanks for your review (and Valery's, which I've just sent a reply to).
In my reply to Valery, I indicated that I didn't quite agree with the proposed parameter name changes (which you said you did agree with). So that may need further discussion.
Thanks again,
Barbara
 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for the SECDIR review from Valery Smyslov.  Please review and
> respond
> to the remaining items.  In particular, I concur with the recommendations
> about
> precise language around the names of the parameters.
> 
> Section 3.1.  babel-implementation-version.  Is there any guidance on the
> format of this string (or is it free form like a Server: in HTTP)?

It is free-form. Each implementation may choose its own version naming convention.

> Section 3.1.  babel-metric-comp-algorithms, babel-mac-algorithms,
> babel-dtls-cert-types.  Is there any guidance to provide on the delimiter
> between a list of values, or is that explicitly a data model issue?

That is explicitly a data model issue. BBF TR-181 does it differently from YANG.

> Section 3.1. babel-security-supported, babel-mac-algorithms,
> babel-dtls-cert-types.  Consider providing citations on “MAC” and “DTLS”;
> and
> “HMAC-SHA256” and “BLAKE2s”; and “X.509” and “RawPublicKey” (just like
> was done
> for babel-metric-comp-algorithms).

For MAC, HMAC-SHA256, and BLAKE2s I will include reference to ID.draft-ietf-babel-hmac
For DTLS, X.509, and RawPublicKey I will include reference to ID.draft-ietf-babel-dtls
These are the drafts that define these terms in the context of Babel and provide further
references to the specifications that more completely define them.

> Section 3.8.  babel-mac-key-value.
> 
> If the algorithm is based on the HMAC construction
>       [RFC2104], the length MUST be between 0 and the block size of the
>       underlying hash inclusive (where "HMAC-SHA256" block size is 64
>       bytes as described in [RFC4868]).  If the algorithm is "BLAKE2s",
>       the length MUST be between 0 and 32 bytes inclusive, as described
>       in [RFC7693].
> 
> I was under the impression that this was an information model to encode
> generic
> Babel protocol parameter and that the underlying protocol documents fully
> specified the normative behavior.  However, this guidance appears to be
> introducing more restrictive configuration guidance not found in
> draft-ietf-babel-hmac making this document an information model + profile.
> Was
> this intentional?

Per RFC2104 Section 2, "The authentication key K can be of any length up to B, the
   block length of the hash function.  Applications that use keys longer
   than B bytes will first hash the key using H and then use the
   resultant L byte string as the actual key to HMAC." 
When comparing implementations of babel-hmac with HMAC-SHA256, the WG discovered variability
in the "actual key" that resulted from using keys longer than B bytes. The cause
of the variability was in the user interface accepting the input string, and not in the actual
babel-hmac implementation. Standard library functions were being used for HMAC algorithm and
for the UI allowing key entry. Since the user interface is effectively an instantiation
of the information model, the group agreed that the information model should
impose a restriction on the input string that guaranteed interoperability by ensuring
the provided string did not have to be hashed to calculate the "actual key". 

Per section 2.1 in RFC 7693, Key Bytes for BLAKE2s are "0 <= kk <= 32". Since this
is the key length specified by the BLAKE2s RFC, the information model is imposing
exactly this length restriction on the key input parameter. RFC 7693 is normative
to draft-ietf-babel-hmac.

> Section 3.8 and 3.9.  babel-mac-key-test and babel-cert-test.  It would be
> useful to explain the use case for this testing API.

One of the most common problems in configuring security mechanisms is in the format of the input key (hex, ASCII, base64, etc.). When a security mechanism fails to work, it is important for users to be able to trouble-shoot this specific point of failure. This test allows the user to see if what this device think the hash should be is the same as what another device thinks the hash should be or is the same as the hash being sent on the wire. Many ISPs have built a test like this into their ISP-supplied CE routers (invoked using the TR-069 protocol and TR-181 data model).

> Section 5.  Note that operations are also exposed in the information model.
> 
> OLD
> This document defines a set of information model objects and
>    parameters that may be exposed to be visible from other devices
> 
> NEW
> This document defines a set of information model objects,    parameters, and
> operations that may be exposed to be visible from other devices

I'll make this change.

> Section 5.  Per:
> 
> MAC keys are allowed to be as short as zero-length.  This is useful
>   for testing.  Network operators are advised to follow current best
>   practices for key length and generation of keys related to the MAC
>   algorithm associated with the key.  Short (and zero-length) keys and
>   keys that make use of only alphanumeric characters are highly
>   susceptible to brute force attacks.
> 
> Add clarifying text that the information model explicitly enables this brute
> force attack where most of the workload is pushed onto the server (since it
> computes the hash).  Also add a mitigation.  Perhaps something like “This
> information model provides an oracle via the babel-mac-key-test operation
> that
> would enable such a brute force attack.  Operators SHOULD rate limit access
> to
> this operation.”

I'm struggling with this comment in several ways.
 - In most expected instantiations of the information model (a user interface, BBF TR-181, YANG),
and in the context of the protocols that transport and interpret these data models (HTTPS,
TR-069/TR-369, NETCONF/RESTCONF), "operators" have little to no ability to rate limit
specific operations -- unless they are the actual implementers of the management protocols.
In the context of, for example, a person configuring their own home network, the 
only way the "operator" rate limits this is by deciding how frequently they push the button.
If an ISP is managing the home network router via TR-069/TR-369, it's unlikely the ISP
can rate limit through any means other than code implementation. If rate limiting is to
be done via the implementation, then the advice should target implementers. It's common
for managed devices to rate limit execution of various operations.
- Having access to this operation implies the person has permission to manage the router.
If someone has permission to manage the router (and permission to invoke this operation)
and really wants to see what happens if they repeatedly push the button, I'm not sure I 
agree that IETF should be suggesting this person should do things to rate limit their personal
access to this function. 
- I don't completely understand "the workload is pushed onto the server (since it
computes the hash)". Babel has no servers. In NETCONF/RESTCONF model, I think the
managed device is referred to as the server? I'm not a NETCONF/RESTCONF expert.
But is that the server you're thinking of? 
In BBF protocols, there's not a strong client/server
concept, and more just "managed device" and "management system" or "Agent" and "Controller".
But if I assume "server" is referring to the "managed router", then I think your point is that
this test requires the managed router to compute a MAC every time the test is run (which
can impact router performance, especially if the test is repeatedly invoked). ?
If the goal is to determine the key by brute force, I would think they would primarily need
a powerful system that could compute MACs for a known input string using iterative key value
guesses. It should only require a single computation of the MAC for that input string from the 
router. Once the powerful system has a match, perhaps the attacker would want to try a
different input string with to see if the MAC for that also matches, using its guessed key.
But I don't see using this test to be an efficient brute force mechanism, since the attacker would
still have to compute a MAC on their end (for comparison) with each test. It would be always be
slower than just using the output of a single test to iterate against.
Of course, if the attacker can capture Babel packets on the wire with MACs, this would provide them
with equally usable samples to iterate against.
So I don't really see the potential threat from repeated execution of tests as being a brute force attack, 
but rather a denial of service attack. 
But I'm no security expert, so maybe I'm just not understanding how these things work. Are 
multiple MAC samples needed (computed from different input strings) for a successful brute force
attack? If so, how many are needed?

I agree that there could be a statement about impacts of MAC
computation to device performance that could seriously impact the ability of the 
router to route, 
and that Babel information model implementations should rate limit the execution
of this test. 

But I think the normative statement targeting implementers would be better 
placed in the parameter description.

I propose, in the Security Considerations section, add  (after paragraph on key 
exposure):
"The babel-mac-key-test operation requires the device to compute the MAC
every time it is executed. If this operation is executed frequently, it could degrade
the device performance and effectively act as a Denial of Service attack. This is the 
reason this parameter's description recommends rate limiting execution
of the operation."

In the babel-mac-key-test description add "The implementation SHOULD rate
limit execution of this operation to avoid degrading router performance."

-