Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt

From: [email-masked]
Date: Fri, 27 Jul 2001 07:07:42 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF.

	Title		: AAA Registration Keys for Mobile IP
	Author(s)	: C. Perkins, P. Calhoun
	Filename	: draft-ietf-mobileip-aaa-key-08.txt
	Pages		: 11
	Date		: 26-Jul-01
	
AAA servers, such as RADIUS and DIAMETER, are in use within the
Internet today to provide authentication and authorization services
for dial-up computers.  Mobile IP requires strong authentication
between the mobile node and its home agent.  When the mobile node
shares a security association with its home AAA server, however, it
is possible to use that security association to create derivative
security associations between the mobile node and its home agent,
and again between the mobile node and the foreign agent currently
offering connectivity to the mobile node.  This document specifies
extensions to the Mobile IP Registration Reply packet that can be
used to create such security information at the mobile node.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-aaa-key-08.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mobileip-aaa-key-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mobileip-aaa-key-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "junhyuk song" <[email-masked]>
Date: Fri, 27 Jul 2001 21:07:20 +0900

Hi Pat,

I don't see the need for MN-FA shared key while using FAC and MN-AAA authentication.
The AAAH will verify Mobile Node for Foreign Agent with MN-AAA authenticatiion defined in RFC3012.  It seems to me using MN-FA Auth and FAC with MN-AAA Auth together is somewhat redundant.

Besides, I wish you made separate section for RADIUS consideration in your draft.
Further more the RADIUS based AAA case must be noted for DOS attack consideration, because HA will blindly procede Mobile IP signalling and AAA message without MN-HA authentication for the initial RRQ.  Another approach is clearly defining MN-AAA authentication from HA before AAAH procede to generate "Key Material" and "Mn-HA shared key".
It also may be helpful to mandate HA-FA authentication between FA and HA.

Regards,
JH SONG

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 27 Jul 2001 06:51:12 -0700

> The AAAH will verify Mobile Node for Foreign Agent with MN-AAA authenticatiion defined in RFC3012.  It seems to me using MN-FA Auth and FAC with MN-AAA Auth together is somewhat redundant.

It isn't redundant since the AAA and the FA may be owned by separate 
administrative domains. Having said that, no where in the draft does it
state that the MN-FA is to be present if the MN-AAA is present.

> Besides, I wish you made separate section for RADIUS consideration in your draft.

why? This draft discusses how the keys are sent to the mobile node, not
to a RADIUS and/or Diameter device.

The AAA software used is completely irrelevant to this draft (unless I missed
something).

> Further more the RADIUS based AAA case must be noted for DOS attack consideration, because HA will blindly procede Mobile IP signalling and AAA message without MN-HA authentication for the initial…

Right, and this was one of the reasons why we decided to allow the FA to
forward the messages to the AAA infrastructure in Diameter. 3GPP2 decided
to let the HA to the work, and that is simply the wrong approach, and will
lead to DoS attacks. I've brought this up numerous times, and the real fix
is to change how 3GPP2 handles AAA (not necessarily the protocol, but rather
the way it uses RADIUS).

> It also may be helpful to mandate HA-FA authentication between FA and HA.

If keys are generated, yes, but this is not covered by this draft. It seems
like what you are requesting is really in the Diameter Mobile IP application,
and not in this one.

PatC

---

From: "Chae-yong Chong" <[email-masked]>
Date: Sat, 28 Jul 2001 13:23:22 +0900

Oops. sorry for typo..
In the last paragraph I mean "unavoidable" not "avoidable"

----- Original Message ----- 
From: "Chae-yong Chong" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, July 28, 2001 1:11 PM
Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt

> Hi PatC
> Here are some comments about your message.
> 
> ----- Original Message ----- 
> From: "Pat Calhoun" <[email-masked]>
> To: <[email-masked]>
> Cc: "Pat Calhoun" <[email-masked]>
> Sent: Friday, July 27, 2001 10:51 PM
> Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt
> 
> 
> Okay, let's assume the FA and AAAF are controlled by what you called, "separate administrative domain".
> But there must be a security association between FA and AAAF. 
> FAC extension itself does not provide any securicy. However MN-AAA extension with FAC extension provides
> some level of securicy. Isn't it the purpose of  RFC3012 ? RFC3012 states:
>  
>     If the Mobile Node does not have a security association with the
>     Foreign Agent, the Mobile Node MUST include the MN-AAA Authentication
>     extension as defined in section 6. 
>  
>  Does that mean the MN-AAA extension provide equivalent level of securicy of MN-FA? 
> 
> 
> 
> 
> As you know currently Diameter is not the RFC state, so 3GPP2 should have
> a way to use this draft with RADIUS. It's not the wrong approach, it is just for an avoidable
> situation. You know it takes a long time for Diameter to be prevailed. That means
> 3GPP2 should have a interim solution which cooperate this draft with RADIUS.
> 
> > 
> Regards
> Chae-yong

---

From: "Chae-yong Chong" <[email-masked]>
Date: Sat, 28 Jul 2001 13:11:57 +0900

Hi PatC

----- Original Message ----- 
From: "Pat Calhoun" <[email-masked]>
To: <[email-masked]>
Cc: "Pat Calhoun" <[email-masked]>
Sent: Friday, July 27, 2001 10:51 PM
Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt

 

Regards
Chae-yong

---

From: "junhyuk song" <[email-masked]>
Date: Sat, 28 Jul 2001 10:01:26 +0900

Please reade my comment below.

----- Original Message ----- 
From: "Pat Calhoun" <[email-masked]>
To: <[email-masked]>
Cc: "Pat Calhoun" <[email-masked]>
Sent: Friday, July 27, 2001 10:51 PM
Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt

> state that the MN-FA is to be present if the MN-AAA is present.

Yes I agree, AAA and FA may be owned by the separate administrative domains.  That is the where FAC needed right?

May be I misunderstood your Internet Draft 0.7.  It said SHOULD include MN-FA Key Request extension, if there is no MN-FA Security Association.

" If the mobile node does not have a Mobility Security Association
  with the foreign agent, it SHOULD include an MN-FA Key Request extension"

It is same requirement with FAC in RFC3012.

> The AAA software used is completely irrelevant to this draft (unless I missed

Yes, you are right. The rationale behind that request was unlike DIAMETER, RADIUS may have some security issue and your Internet Draft seems like also considering RADIUS based AAA.
 
> is to change how 3GPP2 handles AAA (not necessarily the protocol, but rather

I agree.

> like what you are requesting is really in the Diameter Mobile IP application,

I agree, I was more like request 3GPP2 perspective, since 3GPP2 is currently using RADIUS for AAA.

Regards,
JH SONG

---

From: Pat Calhoun <[email-masked]>
Date: Sat, 28 Jul 2001 16:40:00 -0700

> But there must be a security association between FA and AAAF. 

of course.

> some level of securicy. Isn't it the purpose of  RFC3012 ? RFC3012 states:

FAC provides replay protection, not authentication. The MN-AAA piggy backs
the security authentication between the FA-AAAF, and then the AAAF-AAAH.

So, a secure Diameter message is a replacement for MN-FA and FA-HA. Of course,
you don't want to always invoke the overhead of AAA, hence key distribution.

>  Does that mean the MN-AAA extension provide equivalent level of securicy of MN-FA? 

MN-AAA combined with the AAA infrastructure security across both domains.

> 3GPP2 should have a interim solution which cooperate this draft with RADIUS.

Right, we we cannot re-write RADIUS for it to be secure. There is only so
much that we can do, given the way RADIUS works. So the issues raised have
nothing to do with this draft, but rather RADIUS weaknesses.

Thanks,

PatC

---

From: Jouni Malinen <[email-masked]>
Date: Mon, 30 Jul 2001 19:26:33 +0300

aaa-key-08 draft has following text in chapter 1:
...
                                                                 When
   the Mobile IP Registration Reply packet is authenticated by the
   MN-AAA Authentication Extension [3], the mobile node can verify that
   the keys contained in the extensions were produced by the AAA server,
   and thus may be reliably used to create security associations with
   the home agent, or alternatively with the foreign agent.
...

I.e., it specifies that MN can use MN-AAA auth ext to authenticate
registration _reply_. However, RFC 3012, chapter 6 has following
requirement which seems to conflict with the text above:
...
                                  The mobile node MAY include a MN-AAA
   Authentication extension in any Registration Request.  The
   corresponding response MUST include the MN-HA Authentication
   Extension, and MUST NOT include the MN-AAA Authentication Extension.
...

In addition, aaa-key draft does not require that MN-AAA auth ext
protects MN-FA or MN-HA key material from AAA extensions. Chapter 2,
items 7 and 8 require that the Reply passes authentication before MN
generates the key using key material provided.

Am I correct in assuming, that the validation must be done by first
generating temporary keys based on key material and then checking the
MN-HA / MN-FA auth ext (that are required to be in the reply
containing corresponding key material)? Only if this validation is
successful, the temporary keys are actually taken into use. Should
this be explained in more details? At least the introduction talking
about MN-AAA auth ext in registration reply should be fixed.

-- 
Jouni Malinen                                            PGP id EFC895FA