[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

Resent-Message-Id: <200503022014.j22KEB4o015519@rotala.raleigh.ibm.com>
Subject: RE: draft-carroll-dynmobileip-cdma-04.txt -Vendor Specific EAP messages
Date: Wed, 16 Feb 2005 10:28:39 -0500
From: "Carroll, Christopher P." <Christopher.Carroll@ropesgray.com>
To: "Thomas Narten" <narten@us.ibm.com>
Cc: "Frank Quick" <fquick@qualcomm.com>,
        "RFC Editor" <rfc-editor@rfc-editor.org>,
        gerry.flynn@verizonwireless.com, "Russ Housley" <housley@vigilsec.com>,
        "Sam Hartman" <hartmans-ietf@mit.edu>,
        "David Kessens" <david.kessens@nokia.com>
X-OriginalArrivalTime: 16 Feb 2005 15:28:40.0317 (UTC) FILETIME=[3108A2D0:01C5143C]
Resent-To: aaa-doctors@ops.ietf.org
Resent-Date: Wed, 02 Mar 2005 15:14:11 -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,

According to RFC 3579 and RFC 3748, it appears possible to use a
Vendor-Specific EAP message in the RADIUS Access-Reject contrary to the
philosophical objection that VSAs must not be included.  In fact, it
appears that a Vendor-Specific EAP message could perform the same
function as the MIP_Key_Update_Request attribute in question.

In RFC 3579, Sect 2.6.3. Conflicting Messages, only the following SHOULD
NOT be used:

Access-Reject/EAP-Message/EAP Success
Access-Reject/no EAP-Message attribute
Access-Reject/EAP-Start

This indicates that EAP Vendor Specific messages, among other EAP
messages, may be used in a RADIUS Access-Reject.  

RFC 3748 includes Sect 5.7.  Expanded Types

   Description

      Since many of the existing uses of EAP are vendor-specific, the
      Expanded method Type is available to allow vendors to support
      their own Expanded Types not suitable for general usage.

      The Expanded Type is also used to expand the global Method Type
      space beyond the original 255 values.  A Vendor-Id of 0 maps the
      original 255 possible Types onto a space of 2^32-1 possible Types.
      (Type 0 is only used in a Nak Response to indicate no acceptable
      alternative).

      An implementation that supports the Expanded attribute MUST treat
      EAP Types that are less than 256 equivalently, whether they appear
      as a single octet or as the 32-bit Vendor-Type within an Expanded
      Type where Vendor-Id is 0.  Peers not equipped to interpret the
      Expanded Type MUST send a Nak as described in Section 5.3.1, and
      negotiate a more suitable authentication method.

      A summary of the Expanded Type format is shown below.  The fields
      are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |               Vendor-Id                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Vendor-Type                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Vendor data...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      254 for Expanded Type

   Vendor-Id

      The Vendor-Id is 3 octets and represents the SMI Network
      Management Private Enterprise Code of the Vendor in network byte
      order, as allocated by IANA.  A Vendor-Id of zero is reserved for
      use by the IETF in providing an expanded global EAP Type space.

   Vendor-Type

      The Vendor-Type field is four octets and represents the vendor-
      specific method Type.

      If the Vendor-Id is zero, the Vendor-Type field is an extension
      and superset of the existing namespace for EAP Types.  The first
      256 Types are reserved for compatibility with single-octet EAP
      Types that have already been assigned or may be assigned in the
      future.  Thus, EAP Types from 0 through 255 are semantically
      identical, whether they appear as single octet EAP Types or as

      Vendor-Types when Vendor-Id is zero.  There is one exception to
      this rule: Expanded Nak and Legacy Nak packets share the same
      Type, but must be treated differently because they have a
      different format.

   Vendor-Data

      The Vendor-Data field is defined by the vendor.  Where a Vendor-Id
      of zero is present, the Vendor-Data field will be used for
      transporting the contents of EAP methods of Types defined by the
      IETF.

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: Wednesday, February 16, 2005 7:36 AM
To: Frank Quick
Cc: RFC Editor; gerry.flynn@verizonwireless.com; Carroll, Christopher
P.; Russ Housley; Sam Hartman; David Kessens
Subject: Re: draft-carroll-dynmobileip-cdma-04.txt 

Frank Quick <fquick@qualcomm.com> writes:

> The discussion of this central issue terminated shortly after I
pointed out 
> that RFC 2869, Radius extensions contains three attributes that are
added 
> as allowed in access-reject (see 5.19).  Perhaps we can continue the 
> discussion.

I'm all in favor of getting as much understanding on this issue as
possible.

A followup to your remarks:

> The RFC 2865 prohibition is strictly adhered to in all RADIUS RFCs -
the
> only attributes allowed in an Access-Reject are those which can inform
the
> user as to why they have been denied access (Reply-Message,
> EAP-Message/Failure, etc.) or those that route the message to the
right
> NAS/Port/User (Proxy-State, etc.).

> In particular, VSAs MUST NOT be included within an Access-Reject,
since
> that would open the door to providing service to users to whom access
has
> been denied.  Given the MUST NOT, existing NAS devices may silently
> discard these attributes if sent.

> Frank does make an argument that this particular VSA is used for the
> purpose of informing the user that they have been denied access and
need to
> change keys.  However, the document also requires that the NAS not
tear
> down service to the user after receipt of an Access-Reject:

>    Upon receipt of an Access Reject containing the
>    MIP_Key_Update_Request VSA, PDSN MUST send an RRP to the MN with
the
>    MIP_Key_Request VSE.  The PDSN MUST use the RRP error code = 89
>    (Vendor Specific) and MUST not tear down the PPP session after
>    transmission.

> So overall, I'm not clear about whether in fact Access has been
denied, or
> not.  The test would be whether the user could gain the ability to
send a
> network layer packet (e.g. complete IPCP) without having to
> reauthenticate.

> Had such an attribute been sent within an Access-Challenge rather than
an
> Access-Reject, there would be no issue at all.  I'd also argue that if
a
> standard attribute had been used, rather than a VSA (such as if the
> message were sent within a Reply-Message attribute), there would be no
> issue.

Thomas

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