[Mip4] questions on Mobile IP Challenge/ response

[Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri at motorola.com>]

> Hi,
> 
> I am looking at the RFC 3012bis draft and aaa-key drafts and have the following questions. 
> I was hoping somebody on this list would be nice and clear my confusion!
> 
> It seems that the RFC 3344 defines 3 registration authentication extensions (MN-FA, MN-HA and FA-HA), but
> calculation of the authenticator within these extensions do not require any keys.
At the same time you, it seems that you can only add an authentication extension,
>  when you have an SA between the two nodes, e.g. you only add an Mobile-Foreign Auth. extension
if Mobile and FA share an SA, while any node can verify the extensions destined for other nodes
> , since no keys are used in calculation of RFC 3344 authenticators, right?
> 
> Now the RFC3012bis defines a new generalized extension for Mobile-any entity authentication and adds AAA
> server as the first example. It is odd that the generalized extension is not backward compatible with the 
> specific ones defined in RFC 3344 (namely for MN-FA and MN-HA), but that is another issue.
> My question is,
> 
> 1- It seems that the new Mobile-AAA auth. extension uses the keys for calculation of authenticator, true?
> The explanation is section 6 is not clear: it says authenticator is computed on the following
> 
> (preceding MIP data || type|| subtype, length, SPI)  *
> 
> but then there is a function call is as follows
> 
> hmac_md5(data, datalen, key, keylength, authenticator) **
> 
> And it is not clear what "data" is? and what is inserted in authenticator field of the extension?
> Is it **? or is it *? or do we add both * and ** to the message? Reading the draft it seems that
we would add just the authenticator * to the message, but from the formulation above it makes
sense to add ** to the message.

> 2-Section 3.2 on FA's processing of registration requests, it says the FA checks on the registration
> request to see Mobile-Foreign Authentication extension includes a challenge. However, that extension
> as defined in RFC 3344 does not include a challenge, so how is this possible?
> 
> 
> 3-In section 3.2 on , it says that the FA checks the authenticator
> within the Mobile-AAA auth. extension for validity.
> If the authenticator data is hashed with a key that only Mobile and AAA server share, how can the FA do that?
>  
4-Finally, I saw on the archive there has been some discussions on what Mobile-AAA shared secret is?
and people suggested passwords or hashes of passwords, anybody has any experience on how this is done?

Thanks,

Madjid

-- 
Mip4 mailing list
Mip4@ietf.org
https://www.ietf.org/mailman/listinfo/mip4