Subject: Re: [OSPF] OSPF HMAC Cryptographic Authentication

From: "Phil Cowburn" <[email-masked]>
Date: Sat, 22 Jul 2006 09:21:44 +0530

Hi,

In Section 5 you've mentioned the block sizes without units. I presume
they are in bytes, but it would be good if you explicitly state this.

I think it might be good to refer to RFC 3174 somewhere.

Also AFAIK RFC 2104 has the C code to compute HMAC when the text input
is fixed in length. SHA algorithms are defined in terms of variable
number of bits. There may thus be some modifications required in HMAC
C code for SHA. You may want to capture this somewhere.

Otherwise the draft looks in good shape and has been long due. Its
time we all moved away from using MD5 to something thats more
stronger.

Is there a similar work for TCP based protocols like LDP and BGP? Or
other routing protocols like RIP (naah .. am not sure if we really
need something like this for RIP) and i-ISIS (for IP)?

Phil

----- Original Message ----
From: Vishwas Manral <[email-masked]>
To: Rohit Gupta <[email-masked]>
Cc: [email-masked]
Sent: Monday, 17 July, 2006 9:54:59 PM
Subject: Re: [OSPF] OSPF HMAC Cryptographic Authentication

Hi Rohit,

The authors of the OSPF RFC have done it very intelligently. By
allowing the KeyId field which is Opaque, the value of the KeyId
itself defines a seperate security association(channel). IT is the
understanding between the two ends, that a particular KeyId identifies
a key as well as the cryptographic algorithm used.

That is the reason we do not need any new fields.

Thanks,
Vishwas

On 7/17/06, Rohit Gupta <[email-masked]> wrote:
> Hi,
>
> I could not see any new field added in the OSPF message. How do you then make out whether the OSPF router is using HMAC-SHA1 algorithm or the MD5 (the normal OSPF authentication algorithm)?
>
> Thanks,
> Rohit
>
> ----- Original Message ----
> From: Manav Bhatia <[email-masked]>
> To: [email-masked]
> Sent: Saturday, 15 July, 2006 5:06:45 AM
> Subject: [OSPF] OSPF HMAC Cryptographic Authentication
>
>
> Hi,
>
> We have just posted a draft that describes a mechanism for authenticating OSPF packets by making use of HMAC algorithm in conjunction with the SHA family of cryptographic hash functions. It would be great if the WG can provide some feedback and comments on the same.
>
> http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha-00.txt
>
> Thanks,
> Manav
>
> > ----- Forwarded Message ----
> > From: [email-masked]
> > To: [email-masked]
> > Sent: Saturday, July 15, 2006 1:20:01 AM
> > Subject: I-D ACTION:draft-bhatia-manral-white-ospf-hmac-sha-00.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> >
> >    Title        : OSPF HMAC Cryptographic Authentication
> >    Author(s)    : M. Bhatia, et al.
> >    Filename    : draft-bhatia-manral-white-ospf-hmac-sha-00.txt
> >    Pages        : 10
> >    Date        : 2006-6-14
> >
> >   This document describes a mechanism for authenticating OSPF packets
> >   by making use of the HMAC algorithm in conjunction with the SHA
> >   family of cryptographic hash functions. Because of the way the hash
> >   functions are used in HMAC construction, the collision attacks
> >   currently known against SHA-1 do not apply.
> >
> >   This will be done in addition to the already documented
> >   authentication schemes described in the base specification.
> >
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha-00.txt
> >
> > To remove yourself from the I-D Announcement list, send a message to
> > [email-masked] with the word unsubscribe in the body of the
> > message.
> > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >
>
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ospf
>
> Sign Up for your FREE eWallet at www.wallet365.com
>
>
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ospf
>

_______________________________________________
OSPF mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf

_______________________________________________
OSPF mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf

---

From: "Vishwas Manral" <[email-masked]>
Date: Sat, 22 Jul 2006 10:30:55 +0530

Hi Phil,

Thanks a lot for the comments as well as for supporting our effort.

Yes, we will note the block size units are bytes. Also we will refer
to RFC3174 for SHA-1 related references. We will also note the
modifications in C code required for the same.

The same effort is underway in IS-IS and RIP too. For IS-IS the draft
is located at:
http://www.ietf.org/internet-drafts/draft-ietf-isis-hmac-sha-00.txt
which has been approved by the working group.

Once we are done with the changes for we can look at changes required
for TCP MD5 signature options required for BGP if any.

Thanks again,
Vishwas

---

From: "Vishwas Manral" <[email-masked]>
Date: Sun, 23 Jul 2006 11:03:59 +0530

Hi Phil,

The reason I believe this document is still not a working group
document is because we posted this only very recently, though we have
worked on the IS-IS effort for quite sometime now.

Yes, we do intend to bring this up as a working group document soon.

We will incorporate the relevent comments in the IS-IS draft too.

Thanks,
Vishwas

On 7/22/06, Phil Cowburn <[email-masked]> wrote:
> Vishwas:
> I have btw similar comments for your i-ISIS draft.
>
> Is there a reason why we have i-ISIS draft as the WG document and OSPF
> as still an individual submission when the contents are so very
> identical?
>
> I trust that it is known that MD5 is weak and can be easily broken,
> and the community needs to move to a stronger authentication algorithm
> - something like SHA-1, SHA-256 for securing the OSPF packets. I find
> this all the more essential for OSPF when compared to i-ISIS as the
> former runs on top of IP while the latter runs directly over L2 (and
> thus packets cannot be launched multiple hops away).
>
> Phil
>
> >

---

From: Manav Bhatia <[email-masked]>
Date: Tue, 25 Jul 2006 14:34:33 +0000 (GMT)

Hi Phil,
 
RFC 2104 has the C code that allows the text being hashed to be of an arbitary length; the only restriction imposed is that the length must be a multiple of 8 bits (octet). If you look at draft-eastlake-sha2-02.txt then it allows the text to be hashed to contain an arbitary number of bits.
 
Similarly, the code in RFC 3174 is a "byte-level"implementation. The same draft allows the text to be of an arbitary length. It adds to the RFC 3174 API an additional call,
SHA1FinalBits(), that lets the remaining bits to be added to the hash.

I would prefer to refer to this draft as it (i) has full support for all the SHA2 algorithms and (ii) adds HMAC support for both SHA1 and SHA2 algorithms.
 
Thanks,
Manav

----- Original Message ----
From: Phil Cowburn <[email-masked]>
To: [email-masked]; [email-masked]
Cc: [email-masked]
Sent: Saturday, 22 July, 2006 9:21:44 AM
Subject: Re: [OSPF] OSPF HMAC Cryptographic Authentication

Hi,

Phil

----- Original Message ----
From: Vishwas Manral <[email-masked]>
To: Rohit Gupta <[email-masked]>
Cc: [email-masked]
Sent: Monday, 17 July, 2006 9:54:59 PM
Subject: Re: [OSPF] OSPF HMAC Cryptographic Authentication

Hi Rohit,

Thanks,
Vishwas

---

From: "Phil Cowburn" <[email-masked]>
Date: Wed, 26 Jul 2006 05:19:33 +0530

Manav:

=> RFC 2104 has the C code that allows the text being hashed to be of
an arbitary =length; the only restriction imposed is that the length
must be a multiple of 8 bits =(octet). If you look at
draft-eastlake-sha2-02.txt then it allows the text to be =hashed to
contain an arbitary number of bits.

Its been a long time since i read 2104 and i remembered that there
used to be some limitation. I was under the impression that it only
worked for a fixed length of input text T. Clearly, I was mistaken.

=>
=> Similarly, the code in RFC 3174 is a "byte-level"implementation.
The same draft =allows the text to be of an arbitary length. It adds
to the RFC 3174 API an =additional call,
=> SHA1FinalBits(), that lets the remaining bits to be added to the hash.
=>
=> I would prefer to refer to this draft as it (i) has full support
for all the SHA2 =algorithms and (ii) adds HMAC support for both SHA1
and SHA2 algorithms.

I am okay as long as you reference some document for HMAC and SHA algorithms.

Phil

=>
=> Thanks,
=> Manav
=>