Subject: [eap] Proposed Resolution of Issue 56: Expanded Type Format

From: [email-masked] (Bernard Aboba)
Date: Fri, 3 Jan 2003 15:13:27 -0800 (PST)

I've take the liberty of splitting Paul Funk's contribution into two
parts, one for the changes to the Expanded Type format (Issue 56), and the
rest for the changes relating to vendor-specific Nak (Issue 41).

My recommendation is that the proposed resolution of Issue 56 (enclosed
below) be accepted.

Issue 56: Expanded Type format
Submitter name: Paul Funk
Submitter email address: [email-masked]
Date first submitted: December 10, 2002
Document: RFC2284bis-08
Comment type: T
Priority: S
Section: 5.7
Rationale/Explanation of issue:

Out-of-scope changes
--------------------------------
I've taken some liberties that go beyond the scope of this issue.
Feel free to change things back to the way they were if there
are objections:

1 I changed 255 to 254, on the theory that experimental use of
EAP using type 255 is legacy behavior that should not be broken.

2 The original Vendor-specific type has everything after the
Vendor-Id defined by the vendor, with the suggested format of
Vendor-Type immediately following (RADIUS-style). I changed that
to make the format uniform (Diameter-style), so all v-s types have
a fixed format that includes Vendor-Type and are thus interpretable
by anyone. Since Vendor-type is used as part of the protocol when
Nak'ing, it's best to make sure everyone uses it the same way. I
don't believe this limits vendor flexibility.
Proposed Text
---------------------

5.5. Vendor-specific

Description

Due to EAP's popularity, the original Method Type space, which only
provides for 255 values, is being allocated at a pace, which if
continued, would result in exhaustion within a few years. Since many
of the existing uses of EAP are vendor-specific, the Vendor-Specific
Method Type is available to allow vendors to support their own
extended Types not suitable for general usage.

The Vendor-specific 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 namespace of 2^32-1 possible types,
allowing for virtually unlimited expansion. (Note that type 0 is
never used.)

An implementation that supports the Vendor-specific 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 a
Vendor-specific type where Vendor-Id is 0. The single exception
to this rule is the Nak type, as described below.

Peers not equipped to interpret the Vendor-specific Type MUST send a
Nak, and negotiate a more suitable authentication method.

A summary of the Vendor-specific 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 Vendor-specific

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 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.

Vendor-Specific

The Vendor-Specific field is dependent on the vendor's definition of
that attribute. Where a Vendor-Id of zero is present, the Vendor-
Specific field will be used for transporting the contents of EAP
Methods of Types defined by the IETF.

Proposed Resolution: Accept