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

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 16 Jun 2006 12:12:20 -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. 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. 

<snip>

> 
> 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. 

> > 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. 

Vidya

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 16 Jun 2006 14:08:58 -0700

There is an IESG note on the first page of that RFC. 
 
Vidya

________________________________

	From: Behcet Sarikaya [mailto:[email-masked]] 
	Sent: Friday, June 16, 2006 1:55 PM
	To: Narayanan, Vidya
	Cc: [email-masked]
	Subject: Re: [Mipshop] rfc4068bis - MAC Mobility Option for
FBU/FBAck protection

	Hi Vidya,

	----- Original Message ----
	From: "Narayanan, Vidya" <[email-masked]>
	To: Vijay Devarapalli <[email-masked]>
	Cc: [email-masked]
	Sent: Friday, June 16, 2006 1:39:58 PM
	Subject: RE: [Mipshop] rfc4068bis - MAC Mobility Option for
FBU/FBAck protection

	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. 
	
	2. We need a means of indicating the Handover Key Exchange
protocol that
	was used to create the handover key. 
	
	3. There are currently some important issues with RFC4285 - to
mention a
	couple of examples, it specifies the wrong key length for
HMAC-SHA1 and
	has inconsistent definitions of SPI in the document. In order to
use it
	for anything, that RFC needs a revision. 
	
	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. 
	
	==> where is this note, I could not see it? 
	==> WiMAX is recommending the use of this RFC, if there is a
note, WiMAX should also know about it, I think.
	==> Regards,
	==>--behcet
	Vidya
	
	> -----Original Message-----
	> From: Vijay Devarapalli
[mailto:[email-masked]] 
	> Sent: Friday, June 16, 2006 11:27 AM
	> To: Narayanan, Vidya
	> Cc: [email-masked]
	> Subject: Re: [Mipshop] rfc4068bis - MAC Mobility Option for 
	> FBU/FBAck protection
	> 
	> why can't you use the Mobility Message Authentication option 
	> from RFC 4285.
	> 
	>         0                   1                   2
3
	>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 
	> 7 8 9 0 1
	>                         
	> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	>                         |  Option Type  | Option Length |  
	> Subtype      |
	>         
	>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	>         |                  Mobility SPI                       
	>           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	>         |                  Authentication Data ....
	>         
	>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	> >       0                   1                   2
3
	> >       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 
	> 7 8 9 0 1
	> >                                       
	> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	> >                                       |  HKE  |  AT   |    
	> Reserved   |
	> >       
	>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	> >       |                           SPI                       
	>           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	> >     |                         AUTH Data             ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	> > 
	> > 
	> > MH Option Type = "MAC Mobility Option"
	> > 
	> > MH Option Length = Length of the MH data field
	> 
	> these two fields are not shown in the figure.
	> 
	> > 
	> > MH Data Fields: 
	> > 
	> > HKE (4 bits) = Handover Key Exchange Type ('1' - SEND-based;
'2' -
	> > AAA-based;)
	> > 
	> > AT (4 bits) = Algorithm Type - Defined values - '1' -
HMAC-SHA-1 
	> > (default); '2' - HMAC-SHA-256
	> 
	> wouldnt the SPI (and the IP addresses) tell you which key and 
	> which authentication algorithm to use? does it matter if the 
	> key was derived using SEND or AAA network access? for 
	> processing the option, you only need to know which key, right?
	> maybe I am missing something.
	> 
	> Vijay
	>