[Christopher.Carroll@ropesgray.com: RE: draft-carroll-dynmobileip-cdma-04.txt]

[David Kessens <david.kessens@nokia.com>]

----- Forwarded message from "Carroll, Christopher P." <Christopher.Carroll@ropesgray.com> -----

Resent-Message-Id: <200503022011.j22KBuaB015474@rotala.raleigh.ibm.com>
Subject: RE: draft-carroll-dynmobileip-cdma-04.txt 
Date: Tue, 15 Feb 2005 17:16:22 -0500
From: "Carroll, Christopher P." <Christopher.Carroll@ropesgray.com>
To: "Thomas Narten" <narten@us.ibm.com>
Cc: "RFC Editor" <rfc-editor@rfc-editor.org>, gerry.flynn@verizonwireless.com,
        "Russ Housley" <housley@vigilsec.com>,
        "Sam Hartman" <hartmans-ietf@mit.edu>,
        "Frank Quick" <fquick@qualcomm.com>
X-OriginalArrivalTime: 15 Feb 2005 22:16:22.0986 (UTC) FILETIME=[FB81F2A0:01C513AB]
Resent-To: aaa-doctors@ops.ietf.org
Resent-Date: Wed, 02 Mar 2005 15:11:56 -0500
Resent-From: Thomas Narten <narten@us.ibm.com>
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.0.1

Hi Thomas,

It appears that the IETF has recognized that an attribute in the
Access-Reject is acceptable according to RFC 2869 and RFC 3579.
According to sect 2.6.4 of RFC 3579, " A RADIUS Access-Accept or
Access-Reject packet may contain EAP-Message attribute(s)."  Thus,
contrary to your expert's opinion, the inclusion of an attribute is not
"somewhat unique".  Furthermore, the use of an attribute in the
Access-Reject message likely does not represent a major change the
RADIUS security model.

The expert argues "To provision a service to a denied user would imply
that they have not been denied access after all."  Regardless of what is
implied, the user is explicitly denied access until authentication is
successful.  Furthermore, enabling a subsequent cryptographic key
bootstrapping procedure after access is denied is not like redefining a
"Deny" packet filter to allow packets to pass through, or defining a
"null authentication" mode for IKE.  The extension is simply indicating
that the entity can perform a subsequent cryptographic key update.  This
subsequent key update, which itself includes an authentication process,
then establishes the shared secret(s) to enable entity authentication.
The AAA server continues to unambiguously deny access until entity
authentication is successful.

The attribute enables a solution to the most significant problem with
RADIUS which is initial key distribution.  When a device is denied
access by the RADIUS server, it is given the opportunity to establish a
shared secret with the RADIUS server, i.e., perform key distribution.

As I have stated before, initial key distribution is a bootstrapping
problem.  When two entities first meet, there is no existing trust
relationship, i.e., one party will deny access to the other.  Thus, a
mechanism in the denial (e.g., a new RADIUS attribute) that allows the
parties to establish a shared secret is beneficial.

Perhaps the expert can provide a more substantive reason as to why and
how the RADIUS security model would be broken by this attribute.

Regards,

Chris

Christopher Carroll, Esq., CISSP
Ropes & Gray LLP
One International Place
Boston, MA 02110
T: 617-951-7756
F: 617-951-7050

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com] 
Sent: Tuesday, February 15, 2005 1:37 PM
To: Frank Quick
Cc: RFC Editor; gerry.flynn@verizonwireless.com; Carroll, Christopher
P.; Russ Housley; Sam Hartman
Subject: Re: draft-carroll-dynmobileip-cdma-04.txt 

Hi.

The IESG is (once again) going to discuss this document during its
teleconference on Thursday. My hope is we'll come to some closure.

For RFC Editor submissions, the IESG is now using RFC 3932 as a guide
for how to review such submissions. Using 3932 as a guide, the
following point is at issue:

>    5. The IESG thinks that this document extends an IETF protocol in a
>       way that requires IETF review and should therefore not be
>       published without IETF review and IESG approval.

As has been discussed before, the central issue with this document is
its apparent extension of radius, by including an attribute where it
is specifically forbidden to do so via an explicit MUST NOT. Different
people may disagree as to the significance of this change, but one
expert indicates:

> The particular case under discussion is somewhat unique, in that it
not only 
> violates a MUST NOT -- but it also represents a major change to the
security 
> model of the protocol in question.
> 
> Authentication, Authorization and Accounting protocols are built on a
very 
> fundamental idea:  that AAA servers can unambigously allow or deny
access to 
> the network.  Denying access means that the user cannot access network

> services, except possibly to re-attempt authentication.
> 
> RFC 2865 Section 2 states:
> 
> "If desired, the server MAY include a text message in the
Access-Reject
> which MAY be displayed by the client to the user.  No other
> Attributes (except Proxy-State) are permitted in an Access-Reject."
> 
> Table 5.44 of RFC 2865, indicates that inclusion of a vendor-specific
> attribute (or indeed any service provisioning attribute) in an
Access-Reject 
> is a MUST NOT:
> 
>    Request   Accept   Reject   Challenge   #    Attribute
>    0+        0+       0        0+          26   Vendor-Specific
> 
> There is a simple reason for this.
> 
> Since an Access-Reject results in denied access, there is no service
that 
> can be provided to the user, other than perhaps routing the Reject
message 
> to the right NAS or explaining to the user why they have been denied
access. 
>   To provision a service to a denied user would imply that they have
not 
> been denied access after all.
> 
> Provisioning a service with an Access-Reject is like redefining a
"Deny" 
> packet filter to allow packets to pass through, or defining a "null 
> authentication" mode for IKE.
> 
> The RADIUS specifications generally take a lax attitude toward
security, 
> doing only the minimal amount of work to avoid wholesale compromise.
So 
> when MUST NOT language is used, that's  a sign that the practice in
question 
> is not just another bad idea, but so bad that even RADIUS could not
abide 
> it.

Anyway, reviewing some of the mail on this topic, I found:

Frank Quick <fquick@qualcomm.com> writes:

> Date: Wed, 29 Oct 2003 11:04:02 -0800

> I know I received these questions, and I thought that I had even sent
a 
> response, but similarly I can find no record of either.  Subject to 
> comment/change by Verizon, here is a tentative answer.

>    - does this describe something that has already been deployed? If
>      so, by whom and how widely?

> Yes, it's deployed by the vendors supporting Verizon Wireless' 1xEV-DO

> system, which is now commercial in Washington, DC and San Diego, CA.

>    - Is this something that is Verizon-specific? Are other operators
>      using it (or planning on using it)? If Verizon-specific, it would
>      be customary to change the title to make this more clear.

> At the moment it is only in use by Verizon Wireless, however the
intent of 
> publishing is to make it available for others who may wish to use it.

Can you comment on the current state of use/deployment of this system?
Has it expanded beyond what is described above?

Thomsa

----- End forwarded message -----