Subject: Re: [mobile-ip] Why not IKE? (was: Re: Drafty draft about key establishment for Binding Update)

From: James Kempf <[email-masked]>
Date: Mon, 26 Mar 2001 10:22:29 -0800 (PST)

Mike,

> > >Sorry for the confusion. I was summarizing the IESG (and others) concerns
> > >about using AH for solving the mobile IPv6 security problem.
> > >I did not mean to use the word "scale". Hence, if we don't want to use AH
> > >and not solve the authorization problem, why can't we just use the IKE
> > >part alone ? If this is also considered heavy weight, all new solutions
> > >should be compared against this. 
> > >
> > 
> > I won't presume to say I can contribute much to the security discussion, but
> > one concern with IKE is deployment. Some network operators may not
> > want to deploy IKE. Alternative solutions for key distribution (such
> > as AAA) may be more desirable.
>
>
>   Whatever the solution is, it better not rely on
>   AAA exclusively. There is no requirement that AAA
>   be run uniformly. In fact, a pretty large percentage
>   of the devices on the net in the here and now do 
>   not use AAA _at all_. The one I'm typing on right 
>   now is a fine example.
>

I did not say that it should be used exclusively, only that IKE should
not be the only solution due to concerns about widespread
deployment.

With regard to how many devices will use AAA, both
3GPP and 3GPP2 have recently standardized on the IETF AAA architecture
for their all IP core networks. 3GPP2 is in the process of deploying
AAA for mobile IPv4 in their current IOS v4.x with Radius as the protocol,
and in Version C, to be standardized this summer, they intend to
employ Diameter. I believe it is a fair assessment to say that AAA will likely
be widely deployed in telephony networks in the future. 

Perhaps you have some information about similar deployment plans for IKE
that motivated your statement? If so, perhaps you could share it?

		jak

---

From: Michael Thomas <[email-masked]>
Date: Mon, 26 Mar 2001 11:24:18 -0800 (PST)

> not be the only solution due to concerns about widespread

   What do you plan to use to key other SA's?
   AAA as well? If so, I sure hope that somebody
   has got the green light from the AAA chair and
   AD's, not to mention the security AD's.
 
 > that motivated your statement? If so, perhaps you could share it?

   I'm not a huge IKE fan, but I do know that the
   cable MSO's are using Kerberos to key SA's for
   MGCP/SIP, and that there's a real working group
   to really standardize Kerberized IPsec in IETF.
   Using (or not) AAA for a similar general
   purpose keying mechanism really should not be
   done piece meal, and *especially* from MIP WG. 
   If people think that AAA is a good way to key
   SA's, we ought to have a BOF and a real WG to
   set the charter and requirements. As it is
   right, now using AAA to key SA's is an
   amorphous requirementless free for all. Since
   it's a security protocol, that should frighten
   everybody.

		Mike

---

From: Francis Dupont <[email-masked]>
Date: Tue, 27 Mar 2001 12:00:51 +0200

=> I'd prefer to have more general trusted third party but
this has at least open the door.

=> I don't understand your overcautiousness... The security
problems of mobile IPv6 are authentication / authorization
and AAA is supposed to provide them (in a different context).
There are some cases where AAA is clearly a good solution when
it is already available, for instance when a mobile node boots
in a visited network using AAA for its access control (the
local/visited AAA server will contact the home/remote AAA server
giving a timelineness to key SA's using the AAAH as a trusted
third party). Of course mobile IPv6 should not rely on AAA.

Regards

[email-masked]

PS: there were already some discussions about AAA and mobility in
the intersection of AAA and mobile ip WGs, and some I-Ds.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Mar 2001 08:07:30 -0800 (PST)

Francis Dupont writes:
 > => I don't understand your overcautiousness... 

   I'm overcautious because getting security right
   is extremely difficult and fraught with all kinds
   of subtleties that are very easy to miss if you
   aren't extremely critical. For the denizens of
   MIP to have the hubris -- especially at this
   juncture -- to believe that they can make over
   AAA into a key distribution scheme without
   falling into any number of traps is typical,
   but manifestly wrong.

 > The security

   As I've said many times before, AAA was never
   intended as a key distribution scheme. Its
   roots are a PPP client with a symmetric key 
   through a NAS to a AAA without mutual
   authentication. This isn't to say that AAA 
   cannot be transmogrified into a key
   distribution scheme -- anything can. The
   question is whether:

   a) Whether that's an appropriate use,
      and if so, how do we get it right

   b) Whether we end up with something that
      could have been solved with existing
      protocols with the proper peer review,
      etc, etc

 > third party). Of course mobile IPv6 should not rely on AAA.

   AAA may be a good conduit to an existing
   authentication system. In particular, I think
   that marrying AAA with Kerberos would probably
   be a good thing (or more generally, allowing 
   for whatever EAP allows). Otherwise the AAA WG
   is just going to end up reinventing Kerberos 
   for the authentication piece all over again.

	   Mike

---

From: Francis Dupont <[email-masked]>
Date: Tue, 27 Mar 2001 18:36:35 +0200

=> They had the hubris so they tried to use IPsec which is
supposed to be right (for security at least). You know the result!

=> I don't like the term key distribution because AAA is more
a trusted third party but I agree about the traps.
Of course IPsec people can (should!) help: IMHO they can
have a more positive attitude than last week.

      As I've said many times before, AAA was never
      intended as a key distribution scheme.

=> see my previous remark.

      for whatever EAP allows).

=> I prefer the comment. I don't like Kerberos as the ultimate
answer for security (ie. I have at least as many concerns about
Kerberos as you have for AAA :-).

      Otherwise the AAA WG
   
=> There is a big difference: AAA has an architecture, not only
because this is good a priori, but in order to not reinventing
Kerberos with its known weakness (don't scale, no hierarchy,
no distribution, ...).

Regards

---

From: Patrice Calhoun <[email-masked]>
Date: Tue, 27 Mar 2001 08:45:38 -0800 (PST)

>    for the authentication piece all over again.

But the reality is that it *will* happen. Remember here the critical
difference between both Kerberos and AAA, where the mobile does not initially
have access to the network (and therefore cannot contact a kerberos server),
and an intermediate box acts as the mobile's proxy. The mobile, in this case,
speaks Mobile IP with the proxy, and receives its keys via Mobile IP.

So it really isn't fair to state that there is wheel re-invention going on.

Perhaps a better use of your energy is to work with the AAA folks to make sure
that their KDC stuff is solid, instead of hand-waving about security
difficulties. That way, we all benefit at the end with a solid and secure
protocol.

PatC

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Mar 2001 08:59:08 -0800 (PST)

> have access to the network (and therefore cannot contact a kerberos
server),

   Incorrect. That's exactly what IAKERB is
   for. In fact, one of your chairs wrote a 
   draft on exactly this subject for using
   GSSAPI mechanisms for EAP through an IAKERB
   proxy.

   See: draft-aboba-pppext-eapgss-03.txt

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Mar 2001 09:19:27 -0800 (PST)

> supposed to be right (for security at least). You know the result!

   Heh :-)

 > Kerberos as you have for AAA :-).

   Let me be explicit here: my concern is with
   using AAA for something it wasn't designed 
   for in a working group that is not frequented
   by people with security smarts and doesn't even
   have in its charter to solve these classes of
   problems. This has led to problems even where
   a solution for a very MIP related issue --
   BU's to CN's -- without grand ambitions of
   protocol reinvention got blindsided. FWIW, 
   the BU problem was apparent to me after my
   first reading of MIPv6 a year and a half ago...
   I had just assumed that it was obvious to
   everybody else and that the global PKI
   implications were something that the working
   group was willing to live with!

   I was serious when I told James that the
   proponents of using AAA as an alternate means
   of key distribution ought to have a BOF,
   leading potentially to a working group. It's
   possible that there's something new and
   problematic that AAA could solve better 
   even though I have my doubts. However, we'll
   never know until we open this up to an audience
   who has been through all of these arguments
   dozens of times and know the security landscape
   far better than anybody here (and I include
   myself).

 > Kerberos with its known weakness (don't scale, no hierarchy,

   Actually, the addition of PKINIT and PKCROSS
   go a very long way to addressing the scaling
   issues. Since you will always going to run into
   the "global PKI" problem, that isn't really a
   Kerberos problem per se, it's a PKI problem.

		    Mike

---

From: Francis Dupont <[email-masked]>
Date: Tue, 27 Mar 2001 19:57:25 +0200

Let me be explicit here: my concern is with
      using AAA for something it wasn't designed 
      for in a working group that is not frequented
      by people with security smarts

=> is it a working group problem or a "people with security
smarts" problem? I believed the first A of AAA stood for
authentication and the second for authorization...

      and doesn't even have in its charter to solve
      these classes of problems.

=> I believe there is some misunderstanding: I say AAA provides
authentication and authorization, you say it doesn't provide
key distribution...

      This has led to problems even where
      a solution for a very MIP related issue --
      BU's to CN's -- without grand ambitions of
      protocol reinvention got blindsided.

=> BUs to CNs is not in the scope of AAA: AAA is for local network access
control and MN to HA security (look at RFC 2977).

      FWIW, 
   
=> this problem was known but the new fact is that the global PKI is
something not desirable...

      Since you will always going to run into
      the "global PKI" problem, that isn't really a
      Kerberos problem per se, it's a PKI problem.
   
=> I agree: no protocol will provide authentication between
two random Internet nodes without solving first this problem.
So now (as we heard this problem cannot/should not be solved)
Mobile IPv6 people look at AAA for authentication in some domains
(typically local/visited and home/remote domains) as *an option*
and weak security (which meets minimal requirements, but not too weak)
for random correspondents.
 The problem is to remove some stupid MITMs (but not all because it is
not possible without a global PKI, this seems not to be too difficult) and
DoS vulnerabilities (*harder*). A security threat document is supposed
to help us too (look at draft-glass-mobileip-security-issues-00.txt
but many sections are TBDs).

Regards