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

From: "Chae-yong Chong" <[email-masked]>
Date: Thu, 2 Aug 2001 18:14:18 +0900

Hi.

----- Original Message ----- 
From: "Pat Calhoun" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, July 29, 2001 8:40 AM
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. 
> 
> of course.
> 
> > 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:
> 
> 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.
> 
> >     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? 
> 
> MN-AAA combined with the AAA infrastructure security across both domains.
> 
> > 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.
> 
> 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.
> 

I think you agreed that your draft is not a complete solution in RADIUS based architecture because
some other security association must be present betwen FA and HA. Right?
If so, someone want to use your draft in RADIUS based architecture and they want not to use
IPSec like secuirty protocol betwen FA and HA, then it is vulnerable to the DoS attack not because 
of the security hole of your draft but because of the that of RADIUS. They should
have mandate FA-HA authentication extension in this case, I think.

> Thanks,
> PatC

Thanks
Chae-yong

---

From: "Chae-yong Chong" <[email-masked]>
Date: Thu, 2 Aug 2001 09:24:40 +0900

Hi!
----- Original Message ----- 
From: "Pat Calhoun" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, July 29, 2001 8:40 AM
Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt

Thanks
Chae-yong

---

From: "Chae-yong Chong" <[email-masked]>
Date: Thu, 2 Aug 2001 10:46:51 +0900

----- Original Message ----- 
From: "Pat Calhoun" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, July 29, 2001 8:40 AM
Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-08.txt

Thanks
Chae-yong

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 2 Aug 2001 04:05:15 -0700

> have mandate FA-HA authentication extension in this case, I think.

Isn't this similar to blaming the tire manufacturer about a car's
performance, when the car itself only accepts square tires?

ok, seriously, the original challenge draft didn't include support for
RADIUS, but the authors were forced to add support for it by some folks
that also attend 3GPP2 meetings. The text that you see in the RFC is 
the result of text proposed by folks within 3GPP2.

If, as you state, a denial of service attack is possible on the HA because
RADIUS doesn't lend itself very well to Mobile IP's operational model,
I'm not sure that there's much that the FAC RFC can do to fix that problem.

Now that no new RADIUS development is being done within the IETF, perhaps
it is time for folks to embrace the new AAA work?

Thanks,

PatC

---

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.