Subject: RE: [Mip6] Revised WG charter

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 7 Sep 2006 12:03:10 -0400

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]] 
> Sent: Thursday, September 07, 2006 10:40 AM
> To: Chowdhury, Kuntal; Basavaraj Patil; ext Jari Arkko
> Cc: [email-masked]; Alpesh Patel (alpesh); Kent Leung 
> (kleung); Mohamed Khalil; Haseeb Akhtar; Hirschman, Brent B [CTO]
> Subject: Re: [Mip6] Revised WG charter
> 
> That is certainly one issue.
> 
> The other issue is lack of algorithm agility. As you may 
> know, there have been some recent breakthroughs in 
> cryptanalysis for SHA1. While this work has not yet called 
> use of SHA1 with HMAC into question, it still points up the 
> risk of locking in a single algorithm.
> 
Well, auth protocol won't have to be locked to a single algorithm.
HMAC_SHA-1 was used as it was the best choice at the time of publishing
the spec. As with any other spec e.g. MIP4, there is always a
possibility that the best algorithm today is not so good in the future.
So, auth protocol should not be singled out as the ONLY IETF documented
protocol for this point. 
If HMAC_SHA-1 is indeed broken in the future, the NEW devices can use a
different SPI pointing to a _not_yet_broken_ algorithm.

> When you say you plan to update the I-D, do you mean the 
> motivation ID which is mentioned in the charter?
> 
No, I mean the auth protocol i.e. RFC4285.

>             jak
> 
> ----- Original Message -----
> From: "Chowdhury, Kuntal" <[email-masked]>
> To: "Basavaraj Patil" <[email-masked]>; "ext Jari Arkko" 
> <[email-masked]>; "James Kempf" <[email-masked]>
> Cc: <[email-masked]>; "Alpesh Patel (alpesh)" 
> <[email-masked]>; "Kent Leung (kleung)" <[email-masked]>; 
> "Mohamed Khalil" <[email-masked]>; "Haseeb Akhtar" 
> <[email-masked]>; "Hirschman, Brent B [CTO]" 
> <[email-masked]>
> Sent: Thursday, September 07, 2006 7:10 AM
> Subject: RE: [Mip6] Revised WG charter
> 
> 
> If the issue is the key length in HMAC_SHA-1 computation, we 
> plan to update the I-D with the correct MN-HA key length size shortly.
> 
> -Kuntal
> 
> 
> > -----Original Message-----
> > From: Basavaraj Patil [mailto:[email-masked]]
> > Sent: Wednesday, September 06, 2006 10:30 PM
> > To: ext Jari Arkko; James Kempf
> > Cc: [email-masked]
> > Subject: Re: [Mip6] Revised WG charter
> >
> >
> > James,
> >
> > If you could provide text describing the issue, I would be glad to 
> > incorporate it into the I-D.
> >
> > -Raj
> >
> >
> > On 9/5/06 1:16 PM, "ext Jari Arkko" <[email-masked]> wrote:
> >
> > > James Kempf wrote:
> > >
> > >> A list of concerns ought to include the technical issues 
> with the 
> > >> current document, as well as the architectural issues that were 
> > >> discussed during the WG discussion prior to publication.
> > >
> > > Yes.
> > >
> > > --jari
> > >
> >
> >
> > _______________________________________________
> > Mip6 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mip6
> >
> 
> 
> "This email message and any attachments are confidential 
> information of Starent Networks, Corp. The information 
> transmitted may not be used to create or change any 
> contractual obligations of Starent Networks, Corp.  Any 
> review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon this e-mail and its 
> attachments by persons or entities other than the intended 
> recipient is prohibited. If you are not the intended 
> recipient, please notify the sender immediately -- by 
> replying to this message or by sending an email to 
> [email-masked] -- and destroy all copies of 
> this message and any attachments without reading or 
> disclosing their contents. Thank you." 
> 
> 

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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 7 Sep 2006 09:29:14 -0700

Kuntal,

jak>> The way to handle this problem is to build algorithm agility into the 
protocol.  There are a couple of ways it could be put into the current 
protocol without making large modifications in the on the wire format. For 
example, the Subtype field is currently weakly specified. This could be more 
strongly constrainted to include an indication of the authenticator 
construction algorithm. Or, the algorithm type could be included as part of 
the SPI. Alternatively, the on the wire format could be modified to include 
an algorithm type field, if there has as yet been little or no 
implementation and deployment.

jak>> I'm a bit suprised that this point was not brought up prior to 
publication approval by the IESG. Though, reading the IESG note, I suppose 
they figured that should be enough to warn people off from actually using 
the protocol. :-)  If it looks like this protocol is going to have 
significant deployment momentum, perhaps it would make sense to do a 
thorough rewrite and put it throught SAAG.

jak>> Then it's not an ID, it's a published RFC. Modifying it will require a 
bis draft, and WG review, etc. if you are intending to submit this as a WG 
item. If so, then I think it should be included in the charter. If you are 
intending to submit it as an individual draft, then I'd still strongly 
suggest getting some security review on it. It will increase confidence that 
the protocol is sound.

            jak