Subject: Re: Some comments on BFD Authentication ..

From: Jeffrey Haas <[email-masked]>
Date: Sat, 1 Nov 2008 16:10:24 -0400

Manav,

Not speaking as a chair nor specifically for the authors:

On Sat, Nov 01, 2008 at 12:16:50AM +0530, Bhatia, Manav (Manav) wrote:
> It states that the Auth Key/Checksum field (btw this field is a really
> not a "checksum" per se) must be filled with the key that is being used
> to compute the MD5/SHA1 hash. So what happens if the key size is less
> than the hash size?

The relevant point in the document is in 6.7.4:
:   Transmission Using Keyed SHA1 and Meticulous Keyed SHA1
:   Authentication
:
:      The Auth Type field MUST be set to 4 (Keyed SHA1) or 5 (Meticulous
:      Keyed SHA1.)  The Auth Len field MUST be set to 28.  The Auth Key
:      ID field MUST be set to the ID of the current authentication key.

Thus the key MUST be 28 octets long.

I suspect your point is "the key may be ascii text less than 28 octets
long".  In that particular case, each side must choose to populate the
remaining octets in the same fashion.  In my opinion, that's a matter of
local configuration although it argues the maximally portable
configuration syntax is one that allows 28 integers from 0-255 to be
input.

Clearly, for maximal security, a simple passphrase shouldn't be used.

> (b) One of the comments that we received during the GEN-ART review for
> ISIS crypto draft was that 1 octet for a Key ID looked to restrictive.
> Applying the same logic here, can we increase the size of the Key ID
> field to at least 2 octets?

Authentication types 1-5 are, I believe, currently deployed.  Thus we
are unlikely to want to change the size of the key ID in the packet
format.  1 octet provides sufficient space to allow regular rotation of
keys although perhaps it will require more coordination to update the
key set than would be required if the ID space was larger.

If this proves to be a problem in deployment, the base specification
provides the ability to add new authentication types which could have a
larger ID space.

> (c) If you are specifying the cryptographic algorithm details in the
> Auth Type (MD5, SHA1, etc) then the Auth Len is redundant and can be
> simply done away with. One always knows that if the Auth Type is 2-3
> then the size would be 24, etc.

Speaking as a developer, I'm usually pleased to have a consistent format
for my PDUs even if the length component is implied in some cases.
Others may obviously feel differently.

> (d) Why don't we add a generic (crypto-algo independent) authentication
> type (say type 6) in this document? The sender just fills the Key ID,
> the authentication data fields with the hash/digest, and the auth len
> with the size of the digest. The BFD neighbor upon receiving this packet
> would do a lookup in its local database using the key ID carried in the
> packet and determine the auth algo and the secret key associated with it
> to verify the packet.

(Caveat: I am not a cryptographer.)

The security of a given algorithm should not depend on its details being
secret.  Regardless of the cipher in question, we should expect the
security properties of an IETF supported cryptographic algorithm to
depend on the security of the crypto instead of any form of security by
obscurity.

If one were to attempt to do some form of obfuscation, it would require
some amount of arbitrary padding in the authentication portion of the
packet.  In order to give the appearances that this padding is part of
the ciphertext, one would presume it was seeded by a form of
high-entropy random data.  Since BFD is often implemented in line cards,
that alone may be a good reason to not do it.

> It also allows folks to use "non-standard"
> algorithms as that information isn't carried in the BFD packets. Last
> but not the least, we don't need to request IANA for a code point or a
> new RFC to be published, each time a new cryptographic algorithm is
> introduced.

Even if we introduced a "vendor specific" authentication type field, we
would still require some sort of identifier to remove the ambiguity of
whose implementation and which algorithm is being used.  You would still
require a registry to maintain the code points for at least the vendor.

Within the context of the IETF code points for authentication, I
personally find it somewhat improbable that we'll have so many
significant discoveries of cryptographic hash algorithms that we'd
exhaust the remaining key space.  :-)

> We could also have a meticulous generic crypto auth type (type 7?).
> 
> (e) Any specific reason why we're not using the HMAC constructs?

This point was raised in DISCUSS and we're waiting for author response
to this in the updated draft.

-- Jeff

---

From: "Bhatia, Manav \(Manav\)" <[email-masked]>
Date: Sun, 2 Nov 2008 05:23:27 +0530

Jeff,

Thanks for your comments. Please find my response inline.
 
> Thus the key MUST be 28 octets long.

No, this is incorrect - it should be 20 octets long and not 28 as you
state. Auth Len gives the total size of the Authentication Section in
the BFD packet and has no relation with the Key size. 

The following text in the draft gives a hint of the size restrictions
that has been imposed on the key size that should be used:

: The current authentication key value MUST be placed into the Auth
: Key/Checksum field.  A SHA1 checksum MUST be calculated over the
: entire BFD control packet.  The resulting checksum MUST be stored
: in the Auth Key/Checksum field prior to transmission (replacing
: the secret key, which MUST NOT be carried in the packet.)

This means that the operator must be well versed with the hash size that
the underlying hashing algorithm (MD5, SHA-1, SHA-256, etc) would
generate and then the same should be used when constructing the key.
This sounds extremely odd to me. Why should the user password have any
relation with the secret key used in constructing the hash?

> local configuration although it argues the maximally portable

This is exactly my point. The spec needs to spell out how each side
fills the remaining octets if it wants to ensure a consistent behavior.
You could add some text like this:

In the algorithm description below, the following nomenclature, which is
consistent with [FIPS-198], is used: 
    
H    is the specific hashing algorithm (e.g. MD5-, SHA-1, etc). 
K    is the password for the packet given by the user
Ko   is the cryptographic key used with the hash algorithm. 
L    is the length of the hash, measured in octets rather than bits. 
    
Preparation of the 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 K is more than L octets long, then Ko is set to H(K).  If K is less
than L octets long, then Ko is set to the K with zeros appended to the
end of the K such that Ko is L octets long. 

> depend on the security of the crypto instead of any form of 

I agree. 

The idea btw was not to indulge in steganography, but to just provide,
as the name suggested, a generic cryptographic authentication mechanism.
This proposal is not new and already exists in OSPF and ISIS. However, I
agree that it's a trifle too late to add this to the base spec at this
point of time, so I'll withdraw this particular comment.

> that alone may be a good reason to not do it.

Again the idea was not to obfuscate, it was merely to keep the
cryptographic algorithm details out of the BFD packet. This is because
in cryptography, new algorithms surface continuously and existing ones
are continuously attacked - an algorithm believed to be secure today may
be demonstrated to be weak tomorrow. In light of this its best to keep
the protocols/applications (BFD, etc) independent of the underlying
crypto algo being used. You don't later want to publish new RFCs asking
people NOT to support some particular auth types because of the obvious
weaknesses found there. 

To give an idea, DES algo in CBC mode was suggested to be used for IPSEC
[RFC 2405]. However, later when attacks against this particular
algorithm were found, it was removed from the list of mandatory to
implement algorithms for IPSEC [4305].

Applying the same analogy here if there are open weaknesses found in MD5
and SHA-1 tomorrow, then we will have to publish new RFCs in BFD WG
deprecating the use of Auth Types 2,3,4 and 5 and so on with each auth
algo that's exploited in the future. A cleaner way is to keep BFD
independent of the underlying crypto algo details and this can be
achieved by using a generic authentication mechanism that I had
suggested.

You could look at how OSPF [RFC 2328] and IS-IS
[draft-ietf-isis-hmac-sha-06.txt] do their generic crypto
authentication.

So I still stand by the merits of using a generic crypto auth mechanism
however, I withdraw this particular comment as I believe its too late to
update the spec now. We could always add an extension to BFD later .. 

> require a registry to maintain the code points for at least 

No, you wouldn't. The Key ID would map to the BFD security association
and would give all the required details. All that the two ends need to
ensure is that they use the same auth algo, key, etc for the negotiated
key ID. BFD just doesn't care about the underlying details. For all you
know the Auth algo given by the Key ID could be a new NIST approved hash
algo, a proprietary algo or a deprecated algo - BFD would work as long
as the two ends support that.

> exhaust the remaining key space.  :-)

I believe you wanted to say the Auth Type and not the key space here!
:-)

Cheers, Manav

---

From: "Vishwas Manral" <[email-masked]>
Date: Sun, 2 Nov 2008 07:27:04 +0530

Hi Jeff/ Manav,

I have raised similar and some more issues about a couple of months
back. Do have a look at the below and let me know your comments.

www.ietf.org/mail-archive/web/rtg-bfd/current/msg00480.html
www.ietf.org/mail-archive/web/rtg-bfd/current/msg00488.html

Thanks,
Vishwas