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

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

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. 

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. 

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 ....
>         
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Narayanan, Vidya wrote:
> 
> >       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
> 

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 16 Jun 2006 11:50:23 -0700

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

> was used to create the handover key. 

for the option that just carries the MAC, it does not matter
whether the key was derived using SEND or AAA network access.

> for anything, that RFC needs a revision. 

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?

> problems stated above anyway. 

this is a valid point.

Vijay

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 16 Jun 2006 13:54:31 -0700 (PDT)

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

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