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

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

Hi Pete,

Thank you very much for your quick answers. 
Please see inline comments.

Regards,

Madjid

-----Original Message-----
From: Pete McCann [mailto:mccap@lucent.com]
Sent: Thursday, February 19, 2004 3:51 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: mip4@ietf.org
Subject: [Mip4] questions on Mobile IP Challenge/ response



Hi, Madjid,

Nakhjiri Madjid-MNAKHJI1 writes:
 > 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?

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.

Madjid>>Yes, I agree that, if a pair shares an SA, then you need keys for
that SA. However, what I meant (as I understand from the aaa-key draft)
is that originally the MN may only have a pre-shared secret with the AAA
server, and may or may not have an SA with the HA or FA. So if it 
shares an SA with FA, then it will add a Mobile-Foreign Auth. extension to its
registration request (after the Mobile-Foreign Challenge). If it does not
share any SAs, it cannot add the Mobile-Foreign Authentication in its
original registration request, right? (the MN needs to authenticate
to the AAA server)

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

Madjid>>Sure, the draft explains the reason. However, we have types
for 32, 33, 34 for MN-FA, MN-HA, FA-HA auth. extensions in RFC 3344.
but type 36 for generalized auth. extension, with subtype for MN-AAA,
so for historical reason it is messy. It would be nice WHENEVER
the RFC 3344 is revised, we could get this fixed...

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

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.

Madjid>> Thank you, I found the 
hmac_md5(text, text_len, key, key_len, digest)
in the RFC 2104. It makes sense now! Just nitpicking suggestion,
 if the draft had denoted * and ** as follows 

data=(preceding MIP data || type|| subtype, length, SPI)  *
hmac_md5(data, datalen, key, keylength, authenticator) **

with a reference to RFC 2104, it would become easier to follow
for people like me :)

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

Madjid>>Ok, I guess when reading this last part, 
I mistook the "Mobile-Foreign" above as 
"Mobile-Foreign Challenge extension" rather than 
"Mobile-Foreign Authentication extension" And I missed that 
The "challenge extension" means 
the "Mobile-Foreign Challenge extension", which must exist regardless
or whether you have a Mobile-Foreign Auth. extension (if SA exists) or
a Mobile-AAA auth. ext. (if SA does not exist), right?
Too many things to keep straight in the beginning. clear now, thank you. 

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

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.

Madjid>>I looked at the App. B, the way I see it, it is important
to protect the FA from the rouge nodes, before the MN-AAA shared
secret is verified by the AAA and the SAs are distributed. 
However, if it wasn't for distributing the keys, and you only needed
to verify the MN's credentials and could do that at FA (by outsourcing)
then why go all the why the AAA server to do this? This creates
some confusion in the Mobile IP-AAA model (not the key mangement one),
 which says you go from FA to AAAH because AAAH is the only AAA server
 that can verify mobile's credentials and profiles, no?
I don't see why having the FA to check the MN-AAA auth. extension
is necessary (it is not very modular design).
If the foreign domain policy requires authentication to the FA 
in absence of SAs, that is a separate issue (that is actually solved
by verification infrastructure as stated in App B). Say presenting 
certs to the FA and then FA contacting a CA to verify the cert, is
more natural to me than having to use the same MN-AAA key for this? 


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

Madjid>>Agree on the scope, I was just trying the gauge what it is 
done in practice. I guess I need to look at some of the new IETF
security groups for that :)

-Pete

 > Thanks,
 > 
 > Madjid

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