Subject: Re: [mobile-ip] Concerns/comments for aaa-keys and gen-key

From: Michael Thomas <[email-masked]>
Date: Mon, 1 Oct 2001 08:42:23 -0700 (PDT)

Pat Calhoun writes:
 > >    Beyond Eric's clarification, I have a question:
 > >    You clearly must derive new keys from the MN/AAA
 > >    secret which if I remember correctly comes from
 > >    the AAA, encrypted in the MN/AAA key. What prevents
 > >    key reuse, especially for rekeying?
 > 
 > no key is ever sent encrypted or otherwise. All that is sent is keying
 > material, which the mobile uses to create the actual key. The key creation
 > process does require the long term MN/AAA key.

   You didn't answer my question. The question is
   how do you insure that new entropy is added to
   the keying material when you do things like
   rekeying? You can't just derive a new key from
   the old keying material via some one way hash
   generator; you need to add fresh entropy too
   from one or more (preferably) of the 
   participants (MN, HA, AAA).
 
 > > Is there a way
 > >    to get the AAA to supply fresh key material on demand?
 > >    If so, is the performance penalty going to be acceptible?
 > >    If not, is the expectation that one or both of the
 > >    ends of the SA supply entropy? If it's only one side,
 > >    what happens if their random number generator is not
 > >    very good, like oh say open("/dev/null")?
 > 
 > Unfortunately, MIP doesn't have the ability for an unsolicited MIP message
 > to be sent to the mobile. So, using today's protocol, the answer is no.

   No to what? I'm guessing the first, and if so it
   doesn't necessarily need to be initiated by the
   AAA. If the MN can initiate which leads to the AAA
   supplying fresh entropy, that would suffice. With
   normal PPP/AAA, I don't think the host can cause the
   NAS to challenge it. I'm not sure if that's the case
   here.

		Mike

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 2 Oct 2001 07:31:12 -0700

>    participants (MN, HA, AAA).

New keys are always generated by AAA. Furthermore, since the MN authenticates the
Registration Reply, which contains the key material, using the newly generated key,
it requires that both parties have the same key. If the issue here is that a malicious
MIP infrastructure compromises the key, it would require a brute force attack on
the admittedly infrequent registration requests sent by the mobile node.

Lastly, only the AAA generates new keying material for the MN. There is no key
distribution protocol defined between the MN and the HA where they can generate
new keying material without AAA involvement.

>    NAS to challenge it. I'm not sure if that's the case

The MN initiates the key request by issuing a registration request. The MIP
infrastructure cannot cause the MN to register for no reason. The registration
has a lifetime, dictated by the AAA and the HA.

So to answer your question, no the host cannot cause the NAS to challenge it.

PatC