Subject: [Mip4] questions on Mobile IP Challenge/ response

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 19 Feb 2004 14:21:14 -0600

> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/mip4

---

From: Pete McCann <[email-masked]>
Date: Thu, 19 Feb 2004 15:50:36 -0600

Hi, Madjid,

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

This is not correct, keys are most definitely needed between all pairs
of nodes sharing security associations.  See sections 3.5.1 and 5.1 of
RFC 3344.

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

The format change was done in an attempt to be more frugal with the
extension number space, so that we only need to allocate a new subtype
within the authentication extension if we want to create new ones in
the future.

 > 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

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

If you read RFC 2104, this should become more clear: that document
defines the interface to the HMAC function, and if you look closely at
the sample code the "authentictor" is actually the return value of the
function.  So "data" should be set to * and the "authenticator",
returned from the HMAC function, should be filled in to the MN-AAA
authentication extension.

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

That's not quite what the draft says: the challenge value is carried
in an extension separate from the MN-AAA or MN-FA authentication
extension:

   Upon receipt of the Registration Request, if the foreign agent has
   issued a Challenge as part of its Agent Advertisements, and it
   does not have a security association with the mobile node, then
   the Foreign Agent SHOULD check that the Mobile-Foreign Challenge
   extension exists, and that it contains a challenge value previously
   unused by the Mobile Node.  

The FA is required to check that the included challenge comes before
(i.e., is covered by (i.e., included in the HMAC calculation)) an
MN-AAA or MN-FA authentication extension:

   Furthermore, the foreign agent MUST check that there is either a
   Mobile-Foreign, or a Mobile-AAA Authentication extension after
   the Challenge extension.

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

It is outside the scope of the document, but a high-level example is
given in Appendix B and C.  Basically, you need to outsource the
validity check to some other entity that does have the key.

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

You need to set it to a random number of sufficient length.
For example, passwords that might be found in an english dictionary
are unacceptable.  Configuring the key into the MN and AAA servers is
outside the scope of 3012bis.  It is possible that some future work
might address this, but for now you need to do it manually or by some
out-of-band, secure channel.

-Pete