Subject: [mobile-ip] AAA keys design comment

From: Michael Thomas <[email-masked]>
Date: Mon, 1 Oct 2001 10:01:14 -0700 (PDT)

It seems to me that there is a fundamental design
choice that was made in the AAA keys draft is
suboptimal. That is, the basic flow is to have the
AAA deliver keys to both the MN and the HA.  I
think that this is needlessly complex, has either
a race condition, or unneeded latency, and clearly
has an extra message that is not necessary. The
reason is because the MN always needs to register
with HA, so there is a natural and available round
trip that completes the triangle as effectively as
having the AAA doing it. The trick is to have the
AAA create an encrypted blob which is keyed in the
secret between AAAH and HA which the MN can
present to the HA along with an authenticator to
prove it posseses the MN/HA session key.  For
those knowledgeable about Kerberos, this should
look familiar.

A flow is in order here. I'll write this in terms
of Kerberos messages, but I'm not necessarily
saying that it needs to be Kerberos, per se.
The technique is what is important; the bits in
the air are another topic.

MN       FA          AAAF          AAAH             HA
---------->
AS-REQ[HA]
           ------------->
	   AAA+AS-REQ[HA]
                         ------------->
			 AAA+AS-REQ[HA]
                 
                        <--------------
			 AAA+AS-REP [tick HA]
           <------------
   	    AAA+AS-REP [tick HA]
<----------
 AAA+AS-REP [tick HA]

---------------------------------------------------->
AP-REQ [tick HA]

<----------------------------------------------------
AP-REP

Note that all we've done is remove the message
exchange between AAAH, and HA. This yields many 
advantages:

1) this mechanism can be reused for many different
   application at low cost since AAA doesn't need
   to be modified for each new application

2) the mechanism is more robust and properly
   fate shared in that a partition between AAAH 
   and HA will not cause a failure.

3) The latency or race condition between 
   AAA/MN and AAA/HA is eliminated

4) The round trip between AAA and HA is eliminated

5) There's very wide spread use of this approach;
   it's been around for over a decade

6) We _could_ directly use Kerberos messages,
   though I am sympathetic to the desire to have
   something that is less heavy weight if that
   were possible. I believe that directly using
   Kerberos would also provide a solution for
   the IESG criticism that there is an implicit
   expectation that AAAH and HA are in the same
   administrative domain (ie, directly share a
   secret); cross realm Kerberos and/or IAKERB 
   provides the needed functionality. Kerberos
   also brings the ability to use PKI based 
   authentication with PKINIT and PKCROSS. 

On other accounts, I believe that the protocols
are equivalently functional.

		 Mike

---

From: "Fredrik Johansson" <[email-masked]>
Date: Tue, 2 Oct 2001 10:13:24 +0200

>the air are another topic.

what kind of race condition is it that can occur?
this is the message flow for initial registration and
periodic re-keying registrations
MN       FA          AAAF          AAAH             HA
---------->
Mip-RegReq[]
           ------------->
	   AMR[Mip-RegReq]
                         ------------->
			       AMR[Mip-RegReq]
                                        ------------->
                         HAR[Ha and Mn Keys,Mip-RegReq]
                                        <-------------
			             HAA[Mip-RegRep[Mn Keys]]
                         <-------------
                       AMA[FA keys, Mip-RegRep[Mn Keys]]
           <------------
   	    AMA[Fa keys, Mip-RegRep[Mn Keys]]
<----------
 Mip-RegRep[Mn Keys]

this is the message flow for periodic MIP tunnel updates
when distributed keys are still valid
MN       FA          AAAF          AAAH             HA
---------->
Mip-RegReq[]
           ----------------------------------------->
		Mip-RegReq[]
	     <-----------------------------------------
   	      Mip-RegRep[]
<----------
 Mip-RegRep[]

>4) The round trip between AAA and HA is eliminated

Yes, you eliminate the round trip between AAAh and HA,
but you add a potentially much longer round trip between 
the foreing network and the home network in that you now
have to go two round trips between the two networks. The
first one to the AAA and the second one to the HA. As it 
was before, only one round trip was required between the 
home and foreign network. See message flow above

/Fredrik

---

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

> those knowledgeable about Kerberos, this should

so talking about sub-optimal and unnecessarily complex you state that the
MN should issue a request to the KDC infrastructure to retrieve a key, and
then present the key to the HA, right?

This now requires that the signalling (over the air and the 'net) include two
full round trips, as opposed to a single one (which is what we have today).

so perhaps you can qualify your statement on how you perceive your proposal
above as being more efficient, which is key to mobility.

> the air are another topic.

ok, but keet in mind that the AAAH and the HA are many times co-located
and the latency between these is very low. Actually, I'd even argue that
the latency there is lower than introducing a full round trip

for those of you not familiar with the aaa-keys approach, here it is:
 MN       FA          AAAF          AAAH             HA
 ---------->
 REG-REQ
            ------------->
 	   AAA AMR
                          ------------->
 			 AAA AMR
                  
                                       ------------->
 	                       		 AAA HAR
                  
                                      <--------------
              			         AAA HAA

                         <--------------
 			 AAA AMA

            <------------
    	    AAA AMA
 <----------
 REG-REP

The key here is a single round trip, and the over the air signalling is
minimized.

>    to be modified for each new application

ok

>    and HA will not cause a failure.

right, so now the AAAH must assume that the HA can handle the MN. In our 
solution the HA can return a negative response to the AAAH, perhaps because
it is too busy, which would cause the AAAH to select another HA.

In this solution, the MN must recontact the KDC to get new key and try another
HA.

>    AAA/MN and AAA/HA is eliminated

pls describe the race condition, since I am not aware of one.

> 4) The round trip between AAA and HA is eliminated

see comment above on whether this is really the problem

>    authentication with PKINIT and PKCROSS. 

The above two comments seem to be in conflict. Although
Kerberos has been around for a long time, many of the protocols
you mention in 6 are fairly new.

> are equivalently functional.

ok

PatC

---

From: Michael Thomas <[email-masked]>
Date: Tue, 2 Oct 2001 08:15:15 -0700 (PDT)

> periodic re-keying registrations

   I said (probably too briefly) that it was a choice
   between a race condition or extra latency. If the
   AAA blocks to send the message to HA to eliminate the
   race, it adds latency to the entire exchange since
   the AAA could have sent the message to MN with the
   keying material at that step. It also loses robustness
   here because AAA and HA are not fate shared.

 > home and foreign network. See message flow above

   I don't see why this is true. The ticket has
   a lifetime associated with it. The MN creates
   fresh AP-REQ's destined for HA, and all FA needs 
   to do is relay them. The same general technique
   can be used to key the SA's between FA/HA,
   and FA/MN, with complete concurrency. I could
   use the same flow and show how it could key
   all three of those SA's with the same number
   of messages.

   One thing I'm not clear on the v4 version of
   this is whether MN and FA end up sharing their
   own key. Is this the case? If not, isn't there
   an implicit authorization being done for FA
   by HA which constrains the model? Ie, if AAAh and
   HA are not in the same administrative domain
   (eg AAAh == Visa), HA might be granting subsequent
   authorization that AAAh might not have agreed
   to?

		Mike

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 2 Oct 2001 08:13:04 -0700

>    here because AAA and HA are not fate shared.

right, but the AAA is in constant contact with the HAs. So when the
AAA does the HA selection, assuming this is requested, then it would
most likely pick one that has been responding to watchdog messages.

>    authorization that AAAh might not have agreed

No. The key has an explicit lifetime and the AAAH dictates
the key lifetime. This lifetime is how long the MN is granted
access to the network. When that lifetime expires, it requires
new keying, which implies AAA interactions. At that point the
AAAH can deny access.

If the MN moves to a new domain (cross-domain roaming), the AAAH
is again contacted, and has the authority to deny access.

Thanks,

PatC

---

From: Michael Thomas <[email-masked]>
Date: Tue, 2 Oct 2001 09:05:52 -0700 (PDT)

> full round trips, as opposed to a single one (which is what we have  today).

   It appears that I've been thinking of this too
   much like the v6 model which _does_ require the
   round trip to the HA at all times since there's
   no FA. This means that it would have a round
   to MN/HA instead of the round trip from HA/AAAh
   in the v4 case; in other words, a wash on the
   message count front. While you claim that this
   is an expensive round trip vs. a cheap round
   trip, I'm not as certain. First, not all radio
   access media are slow and I would expect that
   in the future they will get much better as they
   become more and more optimized for the net instead
   of the telco. Second, it's not at all clear to
   me that AAA round trip will necessarily be faster
   since there is no reason to believe that AAAh
   and HA will be topologically close to each other.
   This is especially true in the "Visa" model. 
   Indeed, I'm fairly certain that a lot of the 
   latency in current dial (post training, of
   course) is the AAA latency. This effectively
   doubles the message load on the AAA.

   Most of the same criticism still applies though;
   the AAAh are not fate shared with the HA, so
   adding this is less robust, and there is no
   way to do cross-realm AAAh/HA. In fact, you
   are placing a new limitation on who can operate
   the HA's in this model because they must have
   a relationship with AAAh. This model seems to
   preclude the case where I own and operate my 
   own HA, for example, but use a third party 
   settlement scheme for when I'm roaming. This
   doesn't require any business linkage to the
   HA's provider which IMO is a very good thing.

   I'll note that we have yet to have this
   discussion on IPv6. If a similar scheme is
   used, we are explicitly abandoning the "no
   FA" stance for MIPv6 which I think would be
   a step backward.

 > it is too busy, which would cause the AAAH to select another HA.

   If you believe in anycast discovery of HA's,
   wouldn't you be able to achieve the same effect
   more efficiently by having the overloaded HA
   update its route metrics based on load so that
   the MN naturally selects the right HA based on
   routing?

 > you mention in 6 are fairly new.

   The ticket mechanism is really what's important
   here; whether Kerberos itself is the right fit
   is another discussion. I honestly haven't
   sorted through the tradeoffs to form an
   opinion.

		Mike

---

From: "Fredrik Johansson" <[email-masked]>
Date: Wed, 3 Oct 2001 09:38:37 +0200

>   doubles the message load on the AAA.

it's not only the roundtrip over the air that can be
more expensive, it's also between the home and foreign
network (when the HA is allocated in the home network).

>   HA's provider which IMO is a very good thing.

No, there is nothing that mandates a direct relationship
between AAAh and HA, it's enough that the AAAh has a 
relationship (either direct or via a broker) to the AAAf. 
The AAAf can then assign the HA and distribute keys in the
same way as is done for the keys needed for the FA (since 
the AAAh usually don't have a direct trust with the FAs)

/Fredrik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 4 Oct 2001 16:26:32 +0200 (CEST)

> most likely pick one that has been responding to watchdog messages.

Is this notion of "watchdog messages" specified in 
draft-ietf-aaa-diameter-mobileip-07.txt or somewhere else?

I didn't see any mention of it in the above draft.

  Erik

---

From: "Fredrik Johansson" <[email-masked]>
Date: Thu, 4 Oct 2001 16:36:41 +0200

the watchdog mechanism is described in draft-ietf-diameter-07.txt

/Fredrik

>-----Original Message-----
>From: Erik Nordmark [mailto:[email-masked]]
>Sent: den 4 oktober 2001 16:27
>To: Pat Calhoun
>Cc: [email-masked]; Fredrik Johansson; [email-masked]
>Subject: Re: [mobile-ip] AAA keys design comment
>
>

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 4 Oct 2001 16:50:00 +0200 (CEST)

> the watchdog mechanism is described in draft-ietf-diameter-07.txt

draft-ietf-aaa-diameter-07.txt doesn't actually seem to have any
text that describes when watchdog request and reply should and/or
must be used.

In any case, draft-ietf-aaa-diameter-mobileip-07.txt doesn't talk at all
about watchdog. If the intent is that all FA/AAAF and AAAH/HA relationships
keep an open diameter transport that exchanges watchdog messages it seems
to be like it would make sense to document that in that draft.

Or is the unstated assumption that a FA and HA implement all of the diameter
protocol (as opposed to the parts that are explicitly listed in
diameter-mobileip)?

  Erik

---

From: "Fredrik Johansson" <[email-masked]>
Date: Thu, 4 Oct 2001 17:25:09 +0200

>text that describes when watchdog request and reply should and/or

section 5.5  Transport Failure Detection
explains how the watchdog mechanism is used

>to be like it would make sense to document that in that draft.

all diameter peer must implement the base protocol, i.e. the diameter part
in the FA and HA must conform to the base protocol, thus implement the
watchdog
alg.

/Fredrik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 4 Oct 2001 17:55:08 +0200 (CEST)

> explains how the watchdog mechanism is used

Yes, but it doesn't say 
1) that it MUST be used (it uses "recommended" which
   might refer to RFC 2119 per section 1.2 but RFC 2119 only defined
   the upper case "RECOMMENDED"), and
2) section 5.1 and draft-ietf-aaa-diameter-mobileip doesn't say when peer
   connections SHOULD or MUST exist.

In fact 5.1 is quite loose: 
  5.1  Peer Connections

   Although a Diameter node may have many possible peers that it is able
   to communicate with, it may not be economical to have an established
   connection to all of them. At a minimum, a Diameter node SHOULD have
   an established connection with a primary and secondary peer, and MAY
   have additional connections, if it is deemed necessary.

IMHO this must be documented more clearly so that folks can implement
the intent.

> in the FA and HA must conform to the base protocol, thus implement the

This must be stated more clearly in diameter-mobileip.

   Erik

---

From: Michael Thomas <[email-masked]>
Date: Sun, 7 Oct 2001 13:17:31 -0700 (PDT)

> network (when the HA is allocated in the home network).

   I don't see that there's any reason to believe
   that the distance from the AAAh and HA is going
   to be much better on average than the distance
   from FA and HA. AAA's are usually centralized so
   they can service many POP's. Also: since MIPv4
   requires dog leg routing, it seems pretty likely
   that you'd want to engineer the HA's to be topologically
   close to the MN when it initially registers to cut
   down on latency.

 > the AAAh usually don't have a direct trust with the FAs)

   This isn't correct. There *must* be a relationship
   explicitly in the form of a authenticated and authorized
   exchange of the AAA generated keys to the home agent.
   If there weren't, the entire exchange would be insecure.
   There is also implicitly a business arrangement as
   well, and this method of pushing keys pretty much 
   precludes me running my own home agent since Visa
   probably isn't going to want to have scale to anybody
   who wants to become a HA provider.

	     Mike

---

From: Pat Calhoun <[email-masked]>
Date: Sun, 7 Oct 2001 14:41:33 -0700

All of the watchdog (connection reliability text) was pulled from the most
recent draft, and to be included in the next revision of the aaa transport
draft.

This was done at the request of the chair(s) and IESG members.

PatC

---

From: Michael Thomas <[email-masked]>
Date: Mon, 8 Oct 2001 15:15:17 -0700 (PDT)

> most likely pick one that has been responding to watchdog messages.

   But there's still the latency involved; constant
   contact may make the situation worse :-)

 > is again contacted, and has the authority to deny access.

   Isn't it the case that the AAAh has to be contacted
   each time the MN moves? Since the keys are pushed
   from the AAA, the new FA won't have those keys, and
   there's nothing local (FA, AAAf) that has access. 

   One advantage of a Kerberos-like scheme is that
   the MN could get a ticket for either the FA, AAAf
   or both for that matter. Upon movement, the MN
   would present the ticket+authenticator to the new
   FA which could either decrypted directly (assuming
   the FA's had a common keytab), or ship it to the
   AAAf which could locally decrypt it (better, IMO). 
   This also avoids the scary prospect of context 
   transfer of secret keys.

	       Mike