Subject: RE: [Mipshop] rfc4068bis - MAC Mobility Option for FBU/FBAck protection

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 16 Jun 2006 12:22:46 -0700

> > Narayanan, Vidya wrote:
> > > RFC4285 is not a good choice, for some important reasons: 
> > > 
> > > 1. RFC4285 lacks any algorithm agility - so, when HMAC-SHA1 
> > is broken, 
> > > it needs to be revised. By including the Algorithm Type in 
> > the option, 
> > > we take care of that issue.
> > 
> > you need an option to carry the Message Authentication Code. 
> > the algorithm to be used is defined in the key exchange 
> > mechanism (whether SEND or AAA Network Access). the SPI field 
> > is your friend here. the SPI should point to some state that 
> > tells you which key and algorithm to use. not the option. 
> > otherwise you would need to revise FMIPv6, everytime you want 
> > to use a new algorithm.
> 
> Not true. Every time there is a new algorithm, the only thing that is
> needed is IANA registration for that value of the AT field. 

ok. but I still maintain that the key exchange mechanism
decides which authentication algorithm is used. not the
option. for example take the case of IPsec. the algorithm
to be used is not carried in the ESP header. the SPI points
to the security association which in turns tells you what
key and algorithm to use.

> That is the
> whole point of this. And, the SPI is used only for the 
> AAA-based method
> to index the key - in the SEND case, the key is indexed by 
> the CoA alone
> and the SPI is set to 0. 

this is weird. SPI should be used in the SEND case too.

> > I am only suggesting to re-use the option. not the mechanism 
> > described in RFC 4285. I don't think RFC 4285 says this 
> > option MUST be used only with HMAC-SHA1 with a particular 
> key length.
> > on the contrary it defines the option and then it says
> > HMAC-SHA1 is assumed for the protocol defined in spec. not 
> > for the option. see the difference?
> > 
> 
> The option and the option fields are described in RFC4285. The
> Authentication Data field describes how it is calculated and HMAC-SHA1
> (with a wrong key length) is a part of it. If we used that figure and
> re-defined the fields (e.g., SPI or Auth Data), it would have to be a
> new IANA number anyway - at that point, it is a new option. 

RFC 4285 defines how the fields in the option are assigned
when the authentication protocol is used for Mobile IPv6.
it does not mean the fields can be set only to certain 
values. see RFC 4285 again. this is what it says about the 
SPI and the Authentication Data field.

      Mobility SPI:

         Mobility Security Parameter Index

      Authentication Data:

         This field has the information to authenticate the relevant
         mobility entity.  This protects the message beginning at the
         Mobility Header up to and including the mobility SPI field.

there is no mention about the key length or the authentication
algorithm.

> > > 4. Based on the IESG note on RFC4285, it would be 
> > impossible to get a 
> > > standards track document that has RFC4285 as a normative 
> reference.
> > > Actually, I am not in favor of using that as the base, given the 
> > > problems stated above anyway.
> > 
> > this is a valid point.
> > 
> 
> I believe this alone is a reason not to use it. 

could be. but then the reason becomes non-technical.

Vijay

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

---

From: "James Kempf" <[email-masked]>
Date: Fri, 16 Jun 2006 13:06:13 -0700

Vijay,

jak>> Both the SEND and AAA handover key signaling has fields to specify 
what authentication algorithm to use. This is for the FMIP signaling to 
indicate which algorithm the key exchange mechanism specified.

jak>> Why? The SPI is a key name, in SEND it is specified by the CoA. Is 
there some advantage to using it in SEND too?

            jak