Re: [MEXT] Authentication option support in Binding Revocation

[Frank Xia <[e-mail]>]

Hello Gerardo

Please see my inline comments.

BR
Frank

----- Original Message ----- 
From: "Giaretta, Gerardo" <[e-mail]>
To: "Vijay Devarapalli" <[e-mail]>; "Ahmad Muhanna" 
<[e-mail]>; "Sri Gundavelli" <[e-mail]>; "Frank Xia" 
<[e-mail]>
Cc: "Basavaraj Patil" <[e-mail]>; <[e-mail]>
Sent: Monday, July 14, 2008 3:04 PM
Subject: RE: [MEXT] Authentication option support in Binding Revocation


Hi all,

I think the question is: do we really need to support RFC4285 for this?
Where is that requirement coming from?
Frank=>You can refer to 
http://tools.ietf.org/id/draft-ietf-mip6-whyauthdataoption-06.txt.

I think there is a lot of time pressure for these drafts and it would be
good to complete them without extending the support for rfc4285 which is
still an Informational RFC as mentioned by Ahmad.
Frank=>I don't know what is the really problem when referring to rfc4285.
However, I do know some practices that  intended standard tracks
refering to the informational document, RFC4285.
http://tools.ietf.org/id/draft-korhonen-dime-pmip6-03.txt
http://tools.ietf.org/id/draft-korhonen-dime-pmip6-03.txt

Assuming there is some interest, I think a separate draft for the usage
of authentication protocol with MGSM and BRI should be written.
Frank=>Sounds good.

Gerardo

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
Of
> Vijay Devarapalli
> Sent: Saturday, July 12, 2008 9:59 AM
> To: Ahmad Muhanna; Sri Gundavelli; Frank Xia
> Cc: Basavaraj Patil; [e-mail]
> Subject: Re: [MEXT] Authentication option support in Binding
Revocation
>
> > My understanding that Mobile IPv6 Generic Signaling Message (MGSM)
and
> > Binding Revocation are proposed as standard track document.
Therefore,
> > before we start talking about adding Auth protocol support to MGSM
and
> > consequently Binding Revocation, we need to do something
> > about RFC4285.
> > This RFC is still an Informational one and my understanding a
standard
> > track doc can not reference an Informational one.
>
> It doesn't matter. The Generic Signaling Message just needs to
describe
> how to calculate the authentication data if the MN-HA authentication
> option is used. RFC 4285 would be an Informational reference, since it
> is not required for someone to use the Generic Signaling Message.
>
> Vijay
>
> > Any one knows what is the latest on RFC4285? Raj or Kuntal?
> >
> > Regards,
> > Ahmad
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On
> > > Behalf Of Muhanna, Ahmad (RICH1:2H10)
> > > Sent: Saturday, July 12, 2008 7:05 AM
> > > To: Vijay Devarapalli; Sri Gundavelli; Frank Xia
> > > Cc: [e-mail]
> > > Subject: Re: [MEXT] Authentication option support in Binding
> > > Revocation
> > >
> > > Hi Vijay,
> > >
> > > > > Subject: Re: [MEXT] Authentication option support in Binding
> > > > > Revocation
> > > >
> > > > > If there is a shared key between the mobile node and the
> > > > home agent,
> > > > > MN-HA Authentication option can be used.
> > > > >
> > > > > If there is a shared key between the mobile node and the
> > > > AAA, MN-AAA
> > > > > authentication option can be used.
> > > > >
> > > > > But you bring a good point, these options are defined to be
> > > > carried in
> > > > > BU/BA. We need to allow these options to be carried in Generic
> > > > > Notification messages.
> > > >
> > > > Specifying the use of MN-HA authentication option with
> > the Generic
> > > > Signaling Message sounds good to me. I doubt if the MN-AAA
> > > > authentication option will ever be used with the Generic
> > Signaling
> > > > Message, though.
> > >
> > > [Ahmad]
> > > I agree.
> > > If auth protocol to be used to authenticate the MIP6 Generic
> > > Signaling Message, then it has to be the MN-HA AE in the case
> > > of Client MIP6.
> > > MN-AAA AE is used during the initial registration to help in
> > > bootstrapping MN-HA SA if it is needed. After the MIP6
> > > session is established, it is assumed that MN-HA SA has been
> > > established.
> > > Therefore, MN-AAA AE has no value in this scenario. Not only
> > > that, but it does not make sense either.
> > >
> > >
> > > >
> > > > Vijay
> > > > _______________________________________________
> > > > MEXT mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/mext
> > > >
> > > _______________________________________________
> > > MEXT mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/mext
> > >
> >
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext


_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext