Subject: AAA registration keys questions

From: Michael Thomas <[email-masked]>
Date: Tue, 13 Feb 2001 08:17:36 -0800 (PST)

[Hopefully this goes through since Nortel's broken listserv
 is a black hole for subscription requests.]

I've been re-reading draft-ietf-mobileip-aaa-key and have
several questions:

1) How does the HA or FA come to share the same key that
   MN gets through the registration reply? I see that the
   registration reply is encrypted in MN's key, but since
   HA/FA do not possess that key, there needs to be another
   means of transporting it which I didn't see in this
   draft.

   I'm especially curious how the hAAA and FA come to
   share a key directly or indirectly. This is a cross 
   realm problem which is normally what sends up the
   Danger Will Robinson alert.

2) It appears that the draft is focused on symmetric
   key authentication. The requirements draft, however, says
   that public key/certs need to be supported too. The implication 
   of public key authentication is thatthe AAA does not possess a 
   symmetric key with MN, and therefore to transport a symmetric 
   key it must do a public key encryption, which is fairly 
   expensive, and the MN must do a public key decryption which
   is very expensive.
   
   At the very least, the format for transporting the certs,
   signatures, envelopes, etc, still need to be defined.

3) In section 3, step 2 and 4, it has 

   (key XOR (MD5(AAA-key | node-address | AAA-key)))

   I don't understand why AAA-key appears twice since
   they're just OR'ed together. Or does '|' mean
   concatenation?

   Also: I don't understand step 4. Is the MD5 hash
   taken on the hashed key in returned to it in the
   registration reply? It clearly can't be key-AAA
   since it doesn't have it yet. ALso: where is the 
   input of MN's symmetric key? 

   I admit to not being a crypto weenie, but there
   seems like either there's something wrong here, or
   at the very least it could be bit more explicit.

4) I saw no mention of Kerberos in either the requirements 
   or the keying draft. I find this somewhat mystifying since
   Kerberos can generally be set up as an alternate and far
   less CPU intensive counterpart to distributed PKI based 
   schemes, and with the addition of public key authentication
   for Kerberos, can still retain most of the advantages of
   public key based schemes, without many of the well known 
   disadvantages (globally distributed trust hierarchies, 
   CPU scaling problems, the revocation problem). Also, use
   of Kerberos tickets would seemingly address (1) above
   as tickets are two part structures encrypted in the
   client and server's (MN, HA) keys. 

   How exactly this would work, I'm not quite sure, but my
   general impression is that most of these keying efforts
   are feeling around the Kerberos elephant without anybody
   quite grasping what the elephant is.

		       Mike

---

From: Fredrik Johansson <[email-masked]>
Date: Wed, 14 Feb 2001 18:22:14 +0100

Michael,
here are the answers to some of the questions
See comments below.

/Fredrik
>   Danger Will Robinson alert.

The keys destined for the Ha and Fa are transported in diameter messages.
The AAAH will share a secret directly with the HA (if in the home domain)
and can encrypt all keys for the home agent. The AAAH and FA will share a
key indirectly via the AAAF. AAAH will encrypt the keys destined for the FA
with the secret it shares with AAAF, AAAF will then decrypt the keys for the
FA and encrypt them again using the secret it shares with the FA.

>   they're just OR'ed together. Or does '|' mean

Yes, '|' means concatenation.

>   input of MN's symmetric key?

No, the md5 is not taken on the hashed key, the MN recreates the same buffer
as the AAAH does when calculating the md5 hash, i.e. the AAA-key is the
symetric key shared between the MN and AAAH.