Subject: FW: I-D ACTION:draft-bhatia-bfd-crypto-auth-02.txt

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 4 Jun 2010 05:03:45 +0530

Hi,

Now that we're done with the base specs can we get some feedback on this draft? Most of the WGs in the ROUTING area have already moved to HMAC-SHA and we would like BFD also to move from MD5 and keyed-SHA towards stronger crypto algos. In addition to this, it also introduces two new generic authentication types that can be used for specifying any auth algo for BFD. Again nothing new and this is already in place for ISIS, OSPF, etc.

Cheers, Manav

----- Forwarded Message ----
From: "[email-masked]" <[email-masked]>
To: [email-masked]
Sent: Thu, June 3, 2010 10:30:02 PM
Subject: I-D ACTION:draft-bhatia-bfd-crypto-auth-02.txt 

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

    Title        : BFD Generic Cryptographic Authentication
    Author(s)    : M. Bhatia, V. Manral
    Filename    : draft-bhatia-bfd-crypto-auth-02.txt
    Pages        : 12
    Date        : 2010-6-3
    
This document proposes an extension for Bidirectional Forwarding 
Detection (BFD) to allow the use of any cryptographic authentication 
algorithm in addition to the already documented authentication 
schemes, described in the base specification.  

Although this document has been written specifically to introduce two 
new Authentication types it describes how BFD can use National 
Institute of Standards and Technology (NIST) Secure Hash Standard 
family of algorithms (SHS) to authenticate the control packets, the 
method described in this document is generic and can be used to 
extend BFD to support any cryptographic hash function in the future.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-bhatia-bfd-crypto-auth-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--
Manav Bhatia,
IP Division, Alcatel-Lucent,
Bangalore - India

---

From: Minto Jeyananth <[email-masked]>
Date: Thu, 3 Jun 2010 16:38:16 -0700

It's really interesting to see how many protocol implementations exist for SHA and stronger crypto algorithm. 

-minto 

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf
|Of Bhatia, Manav (Manav)
|Sent: Thursday, June 03, 2010 4:34 PM
|To: [email-masked]
|Subject: FW: I-D ACTION:draft-bhatia-bfd-crypto-auth-02.txt
|
|Hi,
|
|Now that we're done with the base specs can we get some feedback on this
|draft? Most of the WGs in the ROUTING area have already moved to HMAC-SHA
|and we would like BFD also to move from MD5 and keyed-SHA towards stronger
|crypto algos. In addition to this, it also introduces two new generic
|authentication types that can be used for specifying any auth algo for BFD.
|Again nothing new and this is already in place for ISIS, OSPF, etc.
|
|Cheers, Manav
|

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 4 Jun 2010 05:26:31 +0530

Minto,

Its already started appearing in the RFPs.

You might also want to look at the work being done in KARP and OPSEC WGs if you havent already.

Cheers, Manav

> -----Original Message-----
> From: Minto Jeyananth [mailto:[email-masked]] 
> Sent: Friday, June 04, 2010 5.08 AM
> To: Bhatia, Manav (Manav); [email-masked]
> Subject: RE: I-D ACTION:draft-bhatia-bfd-crypto-auth-02.txt 
> 
>  
> 
>    It's really interesting to see how many protocol 
> implementations exist for SHA and stronger crypto algorithm. 
> 
> -minto 
> 
> |From: [email-masked] 
> [mailto:[email-masked]] On Behalf

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 18 Jun 2010 23:55:50 +0000

Manav,

[Speaking as co-chair]

We are discussing charter issues with our ADs right now and will likely be
accepting new working group work items in the near future.

On Fri, Jun 04, 2010 at 05:03:45AM +0530, Bhatia, Manav (Manav) wrote:
> Now that we're done with the base specs can we get some feedback on this
> draft? Most of the WGs in the ROUTING area have already moved to HMAC-SHA
> and we would like BFD also to move from MD5 and keyed-SHA towards stronger
> crypto algos. In addition to this, it also introduces two new generic
> authentication types that can be used for specifying any auth algo for
> BFD. Again nothing new and this is already in place for ISIS, OSPF, etc.

[Speaking as an individual contributor]

Your proposal seems reasonable.  As I'm sure you're aware, much of the
procedural review for your text describing HMAC will need help from
outside of the BFD working group.

I think the recommendation that SHA-256 being a MUST may be a bit too strong
at this point in time.  While I certainly wouldn't argue with a
cryptographer about the weakness of the SHA-1/MD5 mechanisms, the level of
protection we get out of them today is probably adequate for a while for
BFD.  Requiring SHA-256, especially with HMAC, may put too much of a burder
on certain implementations over the shorter term.  As such, I'd recommend
that HMAC-SHA1 should be your MUST and that HMAC-256 should be a SHOULD.

(Also, if I understand the algorithms correctly, SHA-2 is different enough
implementation-wise from SHA-1 that hardware assist may require new
silicon.)

-- Jeff

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 19 Jun 2010 05:43:02 +0530

Hi Jeff,
 
> outside of the BFD working group.

Sure. 

Nothing really new here. We have already done this for OSPF in RFC 5709 and IS-IS in RFC 5310.

> that HMAC-SHA1 should be your MUST and that HMAC-256 should 

I agree with you that we could change HMAC-SHA1 as a MUST and HMAC-SHA256 as a SHOULD and all others as a MAY, however, it was while working on RFC 5709 that we changed the requirement for HMAC-256 from a SHOULD to a MUST based on the feedback that we received from the Security ADs. 

Cheers, Manav

---

From: Jeffrey Haas <[email-masked]>
Date: Sat, 19 Jun 2010 00:37:11 +0000

On Sat, Jun 19, 2010 at 05:43:02AM +0530, Bhatia, Manav (Manav) wrote:
> I agree with you that we could change HMAC-SHA1 as a MUST and HMAC-SHA256
> as a SHOULD and all others as a MAY, however, it was while working on RFC
> 5709 that we changed the requirement for HMAC-256 from a SHOULD to a MUST
> based on the feedback that we received from the Security ADs. 

I understand the logic of the security ADs, but I think the result is
potentially unfortunate.  To agree with a prior post by Minto, I think we're
likely to see deployment of SHA-2 based implementations lag the SHA-1
based implementation, but YMMV.  It's only unfortunate in the sense that
this may yield implementations that support multiple keys for SHA-1 but
cannot support the MUST for the SHA-256 MAC.

[Attn: Nobo, et al.]
This incidentally reminds me:  The change to need a index to select the key
will have impacts on the MIB.  In particular, this means that instead of
having a single session key associated with the session, it will be
necessary for the session to point to a key table of some form.

-- Jeff

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 19 Jun 2010 06:19:30 +0530

Hi Jeff,
 
> cannot support the MUST for the SHA-256 MAC.

I think we can start with SHA1 as a MUST and SHA-256 as a SHOULD and all others as a MAY. Do you want me to respin a new version with these changes if there are no further comments. 

BTW given the current trend, we can expect that by the time this draft reaches the IESG most implementations would have anyways started work on moving towards SHA2 (so we can flip the MUSTs and the SHOULDs then)!! ;-)

This draft in addition to introducing HMAC-SHA also introduces a new generic authentication TLV that should be used for auth purposes. This way we don't need to get a new code point from IANA each time we add support for a new algorithm and it also keeps some folks happy as we've minimized the amount of information that we are exposing about the auth that BFD is currently using.

This would put BFD's authentication scheme inline with how its done for IS-IS and OSPF currently.

Cheers, Manav

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sat, 19 Jun 2010 07:04:10 -0700

Hello Jeffrey, Manav, 

> [Attn: Nobo, et al.]
> This incidentally reminds me:  The change to need a index to 
> select the key will have impacts on the MIB.  In particular, 
> this means that instead of having a single session key 
> associated with the session, it will be necessary for the 
> session to point to a key table of some form.

This has been brought up in the past, and consensus at the time swayed
towards nay. Let me take this offline and discuss with couple of folks
first.

Thanx,
Nobo