Subject: [eap] Proposed resolution of issue #41

From: [email-masked] (Paul Funk)
Date: Wed, 11 Dec 2002 20:20:58 -0500

--=====================_-1203455317==_.ALT
Content-Type: text/plain; charset="us-ascii"

Bernard asked me to resend this; it may not have reached the 
entire list.

Paul

--------------------------

Here is a proposed resolution of issue 41 - Nak of extended types.

One thing I learned while writing this proposal: the past tense of 
Nak is "Nak'd", not "Naked".

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.

Interesting implications of this proposal
---------------------------------------------------------
Note that by using single-octet types and vendor-specific types 
in an interchangeable way, it is possible to extend EAP in all 
kinds of ways without breaking backward-compatibility. For example, 
if the authenticator starts the conversation with a vendor-specific 
type (as indicated by the first byte being 254), a legacy peer would 
Nak but a new peer could respond with a vendor-specific type 
(possibly a v-s Nak). Once both parties are talking vendor-specific, 
anything is possible. 

For example, the issue of bi-directional success and failure packets 
could be solved within this context.

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.

5.5.1 Vendor-Specific Nak

   The Vendor-specific type may be Nak'd in either of two ways: Legacy 
   Nak or Vendor-specific Nak

5.5.1.1 Legacy Nak

   The Legacy Nak, consisting of a single octet of value 3, is used to 
   reject Vendor-specific requests entirely. This type of Nak indicates 
   that the Vendor-specific type itself is unacceptable to the peer. 
   This type of Nak provides backward compatibility for peers that 
   implement RFC2284 or earlier. 

   Peer implementations that do support the Vendor-specific type SHOULD 
   NOT use this type of Nak, even as a shortcut to rejecting all possible 
   Vendor-specific methods at once. Future specifications may depend on 
   an authenticator being able to recognize the implementation level of 
   the peer, and eliciting a Nak may provide a means of doing this.

5.5.1.2 Vendor-specific Nak

   The Vendor-specific Nak is a Nak within a Vendor-specific type with 
   Vendor-Id of 0, as shown below:

    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 = 254   |            Vendor-Id = 0                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Vendor-Type = 3                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Desired Types ...
   +
   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Desired Types field contains zero or more Vendor-specific 
   Types, in order of preference, with the most preferred method 
   first; each Type is In order to avoid an interminable negotiation, 
   the Peer MUST only include Types that it is willing to accept.

   Each Type in the Desired Types field MUST be in the form of a 
   Vendor-specific Type, even if it is a Type from the original 
   namespace 1 - 255.

   The Vendor-specific Nak allows individual authentication methods 
   expressed as Vendor-specific Types to be Nak'd, without rejecting 
   the Vendor-specific Type in general. In addition, it permits the 
   peer to list any authentication type -- whether IETF- or vendor-
   defined -- as acceptable.

   An example of a Vendor-specific Nak indicating that MD5-Challenge 
   would be acceptable is shown below:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      254      |                       0                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               3                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       4       |                       0                       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               4                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

--=====================_-1203455317==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Bernard asked me to resend this; it may not have reached the <br>
entire list.<br>
<br>
Paul<br>
<br>
--------------------------<br>
<br>
Here is a proposed resolution of issue 41 - Nak of extended types.<br>
<br>
One thing I learned while writing this proposal: the past tense of <br>
Nak is &quot;Nak'd&quot;, not &quot;Naked&quot;.<br>
<br>
<br>
Out-of-scope changes<br>
--------------------------------<br>
I've taken some liberties that go beyond the scope of this issue. <br>
Feel free to change things back to the way they were if there <br>
are objections:<br>
<br>
1&nbsp;&nbsp; I changed 255 to 254, on the theory that experimental use
of <br>
EAP using type 255 is legacy behavior that should not be broken.<br>
<br>
2&nbsp;&nbsp; The original Vendor-specific type has everything after the
<br>
Vendor-Id defined by the vendor, with the suggested format of <br>
Vendor-Type immediately following (RADIUS-style). I changed that <br>
to make the format uniform (Diameter-style), so all v-s types have <br>
a fixed format that includes Vendor-Type and are thus interpretable 
<br>
by anyone. Since Vendor-type is used as part of the protocol when <br>
Nak'ing, it's best to make sure everyone uses it the same way. I <br>
don't believe this limits vendor flexibility.<br>
<br>
<br>
Interesting implications of this proposal<br>
---------------------------------------------------------<br>
Note that by using single-octet types and vendor-specific types <br>
in an interchangeable way, it is possible to extend EAP in all <br>
kinds of ways without breaking backward-compatibility. For example, 
<br>
if the authenticator starts the conversation with a vendor-specific 
<br>
type (as indicated by the first byte being 254), a legacy peer would
<br>
Nak but a new peer could respond with a vendor-specific type <br>
(possibly a v-s Nak). Once both parties are talking vendor-specific,
<br>
anything is possible. <br>
<br>
For example, the issue of bi-directional success and failure packets
<br>
could be solved within this context.<br>
<br>
<br>
Proposed Text<br>
---------------------<br>
<br>
<tt>5.5.&nbsp; Vendor-specific<br>
<br>
Description<br>
<br>
&nbsp;&nbsp; Due to EAP's popularity, the original Method Type space,
which only<br>
&nbsp;&nbsp; provides for 255 values, is being allocated at a pace, which
if<br>
&nbsp;&nbsp; continued, would result in exhaustion within a few
years.&nbsp; Since many<br>
&nbsp;&nbsp; of the existing uses of EAP are vendor-specific, the
Vendor-Specific<br>
&nbsp;&nbsp; Method Type is available to allow vendors to support their
own<br>
&nbsp;&nbsp; extended Types not suitable for general usage. <br>
<br>
&nbsp;&nbsp; The Vendor-specific type is also used to expand the global
Method <br>
&nbsp;&nbsp; Type space beyond the original 255 values. A Vendor-Id of 0
maps the <br>
&nbsp;&nbsp; original 255 possible types onto a namespace of 2^32-1
possible types, <br>
&nbsp;&nbsp; allowing for virtually unlimited expansion. (Note that type
0 is <br>
&nbsp;&nbsp; never used.)<br>
<br>
&nbsp;&nbsp; An implementation that supports the Vendor-specific
attribute MUST <br>
&nbsp;&nbsp; treat EAP types that are less than 256 equivalently whether
they <br>
&nbsp;&nbsp; appear as a single octet or as the 32-bit Vendor-Type within
a <br>
&nbsp;&nbsp; Vendor-specific type where Vendor-Id is 0. The single
exception <br>
&nbsp;&nbsp; to this rule is the Nak type, as described below.<br>
<br>
&nbsp;&nbsp; Peers not equipped to interpret the Vendor-specific Type
MUST send a<br>
&nbsp;&nbsp; Nak, and negotiate a more suitable authentication
method.<br>
<br>
&nbsp;&nbsp; A summary of the Vendor-specific Type format is shown
below.&nbsp; The<br>
&nbsp;&nbsp; fields are transmitted from left to right.<br>
<br>
&nbsp;&nbsp;&nbsp;
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
3<br>
&nbsp;&nbsp;&nbsp; 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<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; Type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Vendor-Id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Vendor-Type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; | Vendor data ...<br>
&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
<br>
Type<br>
<br>
&nbsp;&nbsp; 254 for Vendor-specific<br>
<br>
Vendor-Id<br>
<br>
&nbsp;&nbsp; The Vendor-Id is 3 octets and represents the SMI Network
Management<br>
&nbsp;&nbsp; Private Enterprise Code of the Vendor in network byte order,
as<br>
&nbsp;&nbsp; allocated by IANA. A Vendor-Id of zero is reserved for use
by the<br>
&nbsp;&nbsp; IETF in providing an expanded global EAP Type space.<br>
<br>
Vendor-Type<br>
<br>
&nbsp;&nbsp; The Vendor-Type field is four octets and represents the
vendor-<br>
&nbsp;&nbsp; specific Method Type. <br>
<br>
&nbsp;&nbsp; If Vendor-Id is zero, the Vendor-Type field is an extension
and <br>
&nbsp;&nbsp; superset of the existing namespace for EAP types. The first
256 <br>
&nbsp;&nbsp; types are reserved for compatibility with single-octet EAP
types <br>
&nbsp;&nbsp; that have already been assigned or may be assigned in the
future.<br>
&nbsp;&nbsp; Thus, EAP types from 0 through 255 are semantically
identical <br>
&nbsp;&nbsp; whether they appear as single octet EAP types or as
Vendor-Types <br>
&nbsp;&nbsp; when Vendor-Id is zero.<br>
<br>
Vendor-Specific<br>
<br>
&nbsp;&nbsp; The Vendor-Specific field is dependent on the vendor's
definition of<br>
&nbsp;&nbsp; that attribute. Where a Vendor-Id of zero is present, the
Vendor-<br>
&nbsp;&nbsp; Specific field will be used for transporting the contents of
EAP<br>
&nbsp;&nbsp; Methods of Types defined by the IETF.<br>
<br>
5.5.1 Vendor-Specific Nak<br>
<br>
&nbsp;&nbsp; The Vendor-specific type may be Nak'd in either of two ways:
Legacy <br>
&nbsp;&nbsp; Nak or Vendor-specific Nak<br>
<br>
5.5.1.1 Legacy Nak<br>
<br>
&nbsp;&nbsp; The Legacy Nak, consisting of a single octet of value 3, is
used to <br>
&nbsp;&nbsp; reject Vendor-specific requests entirely. This type of Nak
indicates <br>
&nbsp;&nbsp; that the Vendor-specific type itself is unacceptable to the
peer. <br>
&nbsp;&nbsp; This type of Nak provides backward compatibility for peers
that <br>
&nbsp;&nbsp; implement RFC2284 or earlier. <br>
<br>
&nbsp;&nbsp; Peer implementations that do support the Vendor-specific
type SHOULD <br>
&nbsp;&nbsp; NOT use this type of Nak, even as a shortcut to rejecting
all possible <br>
&nbsp;&nbsp; Vendor-specific methods at once. Future specifications may
depend on <br>
&nbsp;&nbsp; an authenticator being able to recognize the implementation
level of <br>
&nbsp;&nbsp; the peer, and eliciting a Nak may provide a means of doing
this.<br>
<br>
5.5.1.2 Vendor-specific Nak<br>
<br>
&nbsp;&nbsp; The Vendor-specific Nak is a Nak within a Vendor-specific
type with <br>
&nbsp;&nbsp; Vendor-Id of 0, as shown below:<br>
<br>
&nbsp;&nbsp;&nbsp;
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
3<br>
&nbsp;&nbsp;&nbsp; 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<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; |&nbsp; Type = 254&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Vendor-Id =
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Vendor-Type =
3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Desired Types ...<br>
&nbsp;&nbsp; +<br>
&nbsp;&nbsp; |<br>
&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
<br>
&nbsp;&nbsp; The Desired Types field contains zero or more
Vendor-specific <br>
&nbsp;&nbsp; Types, in order of preference, with the most preferred
method <br>
&nbsp;&nbsp; first; each Type is In order to avoid an interminable
negotiation, <br>
&nbsp;&nbsp; the Peer MUST only include Types that it is willing to
accept.<br>
<br>
&nbsp;&nbsp; Each Type in the Desired Types field MUST be in the form of
a <br>
&nbsp;&nbsp; Vendor-specific Type, even if it is a Type from the original
<br>
&nbsp;&nbsp; namespace 1 - 255.<br>
<br>
&nbsp;&nbsp; The Vendor-specific Nak allows individual authentication
methods <br>
&nbsp;&nbsp; expressed as Vendor-specific Types to be Nak'd, without
rejecting <br>
&nbsp;&nbsp; the Vendor-specific Type in general. In addition, it permits
the <br>
&nbsp;&nbsp; peer to list any authentication type -- whether IETF- or
vendor-<br>
&nbsp;&nbsp; defined -- as acceptable.<br>
<br>
&nbsp;&nbsp; An example of a Vendor-specific Nak indicating that
MD5-Challenge <br>
&nbsp;&nbsp; would be acceptable is shown below:<br>
<br>
&nbsp;&nbsp;&nbsp;
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
3<br>
&nbsp;&nbsp;&nbsp; 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<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
254&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| <br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
<br>
<br>
<div>Paul Funk</div>
<div>Funk Software, Inc.</div>
<div>617 497-6339</div>
<div>[email-masked]</div>
</html>

--=====================_-1203455317==_.ALT--

---

From: [email-masked] (Bernard Aboba)
Date: Sat, 14 Dec 2002 19:49:59 -0800 (PST)

> EAP using type 255 is legacy behavior that should not be broken.

Good idea. We had agreed at IETF 55 to add an experimental Type.
So 255 will be the Experimental Type, and 254 will be for extended
Types.

> by anyone.

This is also a good idea -- the Vendor-Type field as a fixed format of 4
octets as opposed to being of vendor-defined size.

> Since Vendor-type is used as part of the protocol when

Yes.

> (possibly a v-s Nak). Once both parties are talking vendor-specific,

I assume that if the authenticator begins with a V-S type (254), then the
legacy peer would NAK with a single type within the standard space
(4-192).

The RFC 2284bis Peer would respond with:

a. A list of extended types with a single vendorid?
b. A mixture of extended types with different vendorids?
c. Some mixture of standard and extended types?

I wasn't clear what you are advocating in your proposal.

>    reject Vendor-specific requests entirely.

Type=3 is NAK. If you wanted to reject Vendor-Specific requests, why
wouldn't the Legacy client NAK with the type of the method it prefers?

>    implement RFC2284 or earlier.

RFC 2284 states:

      The Nak Type is valid only in Response messages.  It is sent in
      reply to a Request where the desired authentication Type is
      unacceptable.   Authentication Types are numbered 4 and above.
      The Response contains the authentication Type desired by the peer.

So a NAK with a Type=3 in the data field is not legal in a legacy
implementation.

A Vendor-Id = 0 is used to extend the "standard" type space. So presumably
this example packet would only be able to indicate the desire to use
alternative "standard" types, no? Why is a Vendor-Type=3 required to do
this? couldn't the desired types (4 octets) each just be included in a
list fter the initial 4 octets?

>    first

How can Vendor-Specific types be indicated if the Vendor-Id is always = 0
(IETF standard extension space). Or can the Vendor-Id field contain
another value, too? What if the client needs to indicate the desire to do
some mixture of IETF standard and Vendor-Specific Types? Is stacking
possible?

Why couldn't this be indicated by the following payload:

     0                   1                   2                   3

And as an example, could we indicate a preference for Vendor-Id=311, Type
= 15, and then EAP-MD5 as follows:

     0                   1                   2                   3
    |      254      |                     311                       |
    |                               15                              |

---

From: [email-masked] (Paul Funk)
Date: Sun, 15 Dec 2002 14:43:27 -0500

--=====================_172493061==_.ALT
Content-Type: text/plain; charset="us-ascii"

At 07:49 PM 12/14/02 -0800, Bernard Aboba wrote:
...
>legacy peer would NAK with a single type within the standard space

Correct.

>I wasn't clear what you are advocating in your proposal.

The 2284bis Peer would Nak with a mixture of standard and 
extended types. However, all types (including the Nak itself) 
would be in extended (8-octet) format.

The distinction between standard and extended types sort of  
disappears in this proposal. The extended format is a superset of the 
single-octet format, and includes all single-octet types. All single-octet 
types (including Identity, Notification and Nak) map into the extended 
format with Vendor-Id of 0.

>wouldn't the Legacy client NAK with the type of the method it prefers?

It would. My text is misleading. How about this:

The Legacy Nak, consisting of a single octet of value 3 
followed by one or more single-octet Authentication Types 
of value 4 or above, is used to reject Vendor-specific 
requests entirely.  

>So a NAK with a Type=3 in the data field is not legal in a legacy

Correct. My intent was that a Legacy Nak is an ordinary Nak that 
existing pre-2284bis Peer implementations would issue. A 2284bis 
Authenticator, upon receiving a Legacy Nak in response to an extended 
(254) type, would recognize that the Peer doesn't support 2284bis. It 
would therefore interpret the Nak according to the pre-2284bis rules, and 
would desist from offering any other extended authentication types during 
that session.

>some mixture of IETF standard and Vendor-Specific Types? Is stacking

The idea here is that when a 2284bis Peer wants to Nak a 2284bis 
Authenticator's extended (v-s) type, it uses extended types instead 
of single-octet types. 

The Nak type as well as each desired type is in extended format. 

So, the first 8 octets above are interpreted as type Nak, thus indicating that 
this is a Nak response packet. Instead of a single octet of value 3, the Nak is

represented as an extended (vendor-specific) type: the initial 254 indicates
that 
this is an extended type, the Vendor-Id of 0 indicates it is a type from the
IANA 
space, and the Vendor-Type of 3 indicates it is a Nak.

The Desired Types that follow are a list of one or more 8-octet extended 
authentication types that the Peer is willing to use.

Each individual desired type has its own Vendor-Id - 0, 311, 1411, etc.

>Why couldn't this be indicated by the following payload:

There is a typo in my original example, which may be causing confusion. The
single 
octet "4" should be a "254".

Your two examples are correct, except for the omission of the extended Nak 
type itself.

Here's an improved version of my proposed text with example, that includes both

0 and non-0 Vendor-Ids, fixes the typo, and adds some gloss to the type
numbers:

An example is shown below of a Vendor-specific Nak indicating 
the acceptability of two authentication types: (1) MD5-Challenge, 
and (2) a hypothetical type 15 defined by a (not-so-hypothetical) 
vendor with id 311:

 0                   1                   2                   3
|      254      |                 Vendor-Id = 0
    
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Vendor-Type = 3 (Nak)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      254      |                 Vendor-Id = 0
    
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Vendor-Type = 4 (MD5-Challenge)         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      254      |                 Vendor-Id = 311
   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Vendor-Type = 15                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Paul

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

--=====================_172493061==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 07:49 PM 12/14/02 -0800, Bernard Aboba wrote:<br>
...<br>
&gt;&gt; if the authenticator starts the conversation with a
vendor-specific<br>
&gt;&gt; type (as indicated by the first byte being 254), a legacy peer
would<br>
&gt;&gt; Nak but a new peer could respond with a vendor-specific
type<br>
&gt;&gt; (possibly a v-s Nak). Once both parties are talking
vendor-specific,<br>
&gt;&gt; anything is possible.<br>
&gt;<br>
&gt;I assume that if the authenticator begins with a V-S type (254), then
the<br>
&gt;legacy peer would NAK with a single type within the standard
space<br>
&gt;(4-192).<br>
<br>
Correct.<br>
<br>
&gt;<br>
&gt;The RFC 2284bis Peer would respond with:<br>
&gt;<br>
&gt;a. A list of extended types with a single vendorid?<br>
&gt;b. A mixture of extended types with different vendorids?<br>
&gt;c. Some mixture of standard and extended types?<br>
&gt;<br>
&gt;I wasn't clear what you are advocating in your proposal.<br>
<br>
The 2284bis Peer would Nak with a mixture of standard and <br>
extended types. However, all types (including the Nak itself) <br>
would be in extended (8-octet) format.<br>
<br>
The distinction between standard and extended types sort of&nbsp; <br>
disappears in this proposal. The extended format is a superset of the
<br>
single-octet format, and includes all single-octet types. All
single-octet <br>
types (including Identity, Notification and Nak) map into the extended
<br>
format with Vendor-Id of 0.<br>
<br>
&gt;<br>
&gt;&gt; 5.5.1.1 Legacy Nak<br>
&gt;&gt;<br>
&gt;&gt;&nbsp;&nbsp;&nbsp; The Legacy Nak, consisting of a single octet
of value 3, is used to<br>
&gt;&gt;&nbsp;&nbsp;&nbsp; reject Vendor-specific requests 
entirely.<br>
&gt;<br>
&gt;Type=3 is NAK. If you wanted to reject Vendor-Specific requests,
why<br>
&gt;wouldn't the Legacy client NAK with the type of the method it
prefers?<br>
<br>
It would. My text is misleading. How about this:<br>
<br>
<tt>The Legacy Nak, consisting of a single octet of value 3 <br>
followed by one or more single-octet Authentication Types <br>
of value 4 or above, is used to reject Vendor-specific <br>
requests entirely.&nbsp; <br>
<br>
</tt>&gt;<br>
&gt;&gt;&nbsp;&nbsp;&nbsp; This type of Nak provides backward
compatibility for peers that<br>
&gt;&gt;&nbsp;&nbsp;&nbsp; implement RFC2284 or earlier.<br>
&gt;<br>
&gt;RFC 2284 states:<br>
&gt;<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Nak Type is valid only in Response
messages.&nbsp; It is sent in<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reply to a Request where the desired
authentication Type is<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; unacceptable.&nbsp;&nbsp;
Authentication Types are numbered 4 and above.<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Response contains the
authentication Type desired by the peer.<br>
&gt;<br>
&gt;So a NAK with a Type=3 in the data field is not legal in a
legacy<br>
&gt;implementation.<br>
<br>
Correct. My intent was that a Legacy Nak is an ordinary Nak that <br>
existing pre-2284bis Peer implementations would issue. A 2284bis <br>
Authenticator, upon receiving a Legacy Nak in response to an extended
<br>
(254) type, would recognize that the Peer doesn't support 2284bis. It
<br>
would therefore interpret the Nak according to the pre-2284bis rules, and
<br>
would desist from offering any other extended authentication types during
<br>
that session.<br>
<br>
&gt;<br>
<tt>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
3<br>
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; 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<br>
&gt;&gt;&nbsp;&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&gt;&gt;&nbsp;&nbsp;&nbsp; |&nbsp; Type = 254&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Vendor-Id =
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&gt;&gt;&nbsp;&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&gt;&gt;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Vendor-Type =
3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&gt;&gt;&nbsp;&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&gt;&gt;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Desired Types ...<br>
&gt;&gt;&nbsp;&nbsp;&nbsp; +<br>
&gt;&gt;&nbsp;&nbsp;&nbsp; |<br>
&gt;&gt;&nbsp;&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&gt;<br>
</tt>&gt;A Vendor-Id = 0 is used to extend the &quot;standard&quot; type
space. So presumably<br>
&gt;this example packet would only be able to indicate the desire to
use<br>
&gt;alternative &quot;standard&quot; types, no? Why is a Vendor-Type=3
required to do<br>
&gt;this? couldn't the desired types (4 octets) each just be included in
a<br>
&gt;list fter the initial 4 octets?<br>
&gt;<br>
&gt;&gt;&nbsp;&nbsp;&nbsp; The Desired Types field contains zero or more
Vendor-specific<br>
&gt;&gt;&nbsp;&nbsp;&nbsp; Types, in order of preference, with the most
preferred method<br>
&gt;&gt;&nbsp;&nbsp;&nbsp; first<br>
&gt;<br>
&gt;How can Vendor-Specific types be indicated if the Vendor-Id is always
= 0<br>
&gt;(IETF standard extension space). Or can the Vendor-Id field
contain<br>
&gt;another value, too? What if the client needs to indicate the desire
to do<br>
&gt;some mixture of IETF standard and Vendor-Specific Types? Is
stacking<br>
&gt;possible?<br>
<br>
The idea here is that when a 2284bis Peer wants to Nak a 2284bis <br>
Authenticator's extended (v-s) type, it uses extended types instead 
<br>
of single-octet types. <br>
<br>
The Nak type as well as each desired type is in extended format. <br>
<br>
So, the first 8 octets above are interpreted as type Nak, thus indicating
that <br>
this is a Nak response packet. Instead of a single octet of value 3, the
Nak is <br>
represented as an extended (vendor-specific) type: the initial 254
indicates that <br>
this is an extended type, the Vendor-Id of 0 indicates it is a type from
the IANA <br>
space, and the Vendor-Type of 3 indicates it is a Nak.<br>
<br>
The Desired Types that follow are a list of one or more 8-octet extended
<br>
authentication types that the Peer is willing to use.<br>
<br>
Each individual desired type has its own Vendor-Id - 0, 311, 1411,
etc.<br>
<br>
<tt>&gt;<br>
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
3<br>
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; 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<br>
&gt;&gt;&nbsp;&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&gt;&gt;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
254&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&gt;&gt;&nbsp;&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&gt;&gt;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&gt;&gt;&nbsp;&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&gt;&gt;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&gt;&gt;&nbsp;&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&gt;&gt;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&gt;&gt;&nbsp;&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
</tt>&gt;<br>
&gt;Why couldn't this be indicated by the following payload:<br>
&gt;<br>
<tt>&gt;&nbsp;&nbsp;&nbsp;&nbsp;
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
3<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; 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<br>
&gt;&nbsp;&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&gt;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
254&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&gt;&nbsp;&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&gt;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&gt;&nbsp;&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
</tt>&gt;<br>
&gt;And as an example, could we indicate a preference for Vendor-Id=311,
Type<br>
&gt;= 15, and then EAP-MD5 as follows:<br>
&gt;<br>
<tt>&gt;&nbsp;&nbsp;&nbsp;&nbsp;
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
3<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; 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<br>
&gt;&nbsp;&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&gt;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
254&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
311&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&gt;&nbsp;&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&gt;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
15&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&gt;&nbsp;&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&gt;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
254&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&gt;&nbsp;&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&gt;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&gt;&nbsp;&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
<br>
</tt>There is a typo in my original example, which may be causing
confusion. The single <br>
octet &quot;4&quot; should be a &quot;254&quot;.<br>
<br>
Your two examples are correct, except for the omission of the extended
Nak <br>
type itself.<br>
<br>
Here's an improved version of my proposed text with example, that
includes both <br>
0 and non-0 Vendor-Ids, fixes the typo, and adds some gloss to the type
numbers:<br>
<br>
<tt>An example is shown below of a Vendor-specific Nak indicating <br>
the acceptability of two authentication types: (1) MD5-Challenge, <br>
and (2) a hypothetical type 15 defined by a (not-so-hypothetical) <br>
vendor with id 311:<br>
<br>
&nbsp;0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
3<br>
&nbsp;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<br>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 254&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Vendor-Id =
0</tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<tt>|<br>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Vendor-Type = 3
(Nak)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 254&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Vendor-Id =
0</tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<tt>|<br>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Vendor-Type = 4
(MD5-Challenge)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 254&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Vendor-Id =
311</tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<tt>|<br>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Vendor-Type =
15&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
<br>
<br>
</tt>Paul<br>
<br>
<br>
<br>
<br>
<div>Paul Funk</div>
<div>Funk Software, Inc.</div>
<div>617 497-6339</div>
<div>[email-masked]</div>
</html>

--=====================_172493061==_.ALT--

---

From: [email-masked] (Bernard Aboba)
Date: Sun, 15 Dec 2002 11:58:56 -0800 (PST)

> of value 4 or above, is used to reject Vendor-specific

OK.

> would desist from offering any other extended authentication types during

OK.

> The Nak type as well as each desired type is in extended format.

OK. Can the RFC 2248bis Peer respond with an extended Nak to an offer of a
standard (1-255) type from a legacy peer? I think the answer is
yes, since it is assumed that the legacy peer will ignore everything
except the first octet of the type-data (254). It will either counter with
another offer within the standard space, or send an EAP Failure.

> Nak is represented as an extended (vendor-specific) type: the initial
> 254 indicates that

The problem is that the state machine only allows an initial Request
(offer) of a given Type to be answered by a Response of that same Type
(offer acceptance) or a Nak (Type 3). Allowing it to be answered by
a Response of either Type 3 or 254 complicates the state machine.

> Your two examples are correct, except for the omission of the extended Nak

OK. So we're talking about whether a Type of 254 or 3 is used for the NAK
packet itself. Essentially, you are defining a new NAK packet of Type 254,
and I was talking about extended the old NAK packet of Type 3.

> and (2) a hypothetical type 15 defined by a (not-so-hypothetical)

Thanks.

Question -- are there things that you can do by defining a new NAK packet
that you couldn't do by extending the old one? In the case given above the
functionality is similar -- but I assume that the added overhead is also
meant to provide some additional flexibility.

---

From: [email-masked] (Paul Funk)
Date: Sun, 15 Dec 2002 17:01:10 -0500

--=====================_180755843==_.ALT
Content-Type: text/plain; charset="us-ascii"

At 11:58 AM 12/15/02 -0800, Bernard Aboba wrote:
...
>another offer within the standard space, or send an EAP Failure.

Actually, I think it can't. The extended Nak starts with an 8-octet, not 
a 1-octet, Nak. So the type of the packet looks like 254 to the legacy 
authenticator, and it won't understand it at all.

If the 2284bis Peer gets a request in non-extended form, it doesn't know if 
the Authenticator is legacy or 2284bis. It should therefore Nak in non-
extended form as well. If it supports authentication types in the extended 
space, it can include a 254 as a desired type. If the Authenticator is 
legacy, the 254 would be disregarded. If the Authenticator is 2284bis, the 
presence of 254 in a Nak (even if single-octet) indicates that the Peer is 
2284bis, so its next request can be in extended form. Once the Peer 
receives the extended form request, it then Nak extended types 
precisely, since it now knows the Authenticator is also 2284bis.

A 2284bis Authenticator could take the approach of always issuing an 
extended request first, even if the authentication method is a standard 
one such as MD5-Challenge. If the Peer is pre-2284bis it will issue a 
legacy Nak and the Authenticator will drop down to legacy operation. If 
the Peer is 2284bis, it can respond with an extended Nak. This approach 
may cost a round trip when the Peer is pre-2284bis, but when the Peer 
is 2284bis it provides a cleanest negotiation and may save a round trip.

>a Response of either Type 3 or 254 complicates the state machine.

I would suggest that we don't consider 254 a "type". It is really like an 
escape character. So if we understand "type" to be a code point in a 
7-octet space composed of vendor-id and ordinal, and that this code 
point can be represented in either 1 octet or 8 octets (where the 1 octet 
version has limited span), I think the problem goes away.

Yes.

>meant to provide some additional flexibility.

Actually, I don't think of this as defining a new Nak packet, but extending 
the interpretation of the Nak element.

The purpose of the extended Nak packet is to provide backward 
compatibility while preserving equivalent functionality across the entire 
spectrum of types.

This could have be done in a number of ways; any mechanism would have 
to be examined to make sure there are no avenues for misinterpretation 
due to different versions of the standard being supported on Peer and 
Authenticator.

The mechanism of defining an extended type space that comprises 
the original type space seemed to me the least arbitrary, and easily 
verified to be harmless to existing implementations.

I think any added flexibility it provides relates to the ability of a 2284bis
Peer 
and 2284bis Authenticator to discover that they are both indeed 2284bis, 
even if they are using a standard protocol such as MD5-Challenge. If we 
want to add any new features to the protocol, such as Peer response 
to EAP-Success, this could be the avenue to do this without breaking 
existing implementations.

Paul

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

--=====================_180755843==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 11:58 AM 12/15/02 -0800, Bernard Aboba wrote:<br>
...<br>
&gt;&gt; The idea here is that when a 2284bis Peer wants to Nak a
2284bis<br>
&gt;&gt; Authenticator's extended (v-s) type, it uses extended types
instead<br>
&gt;&gt; of single-octet types.<br>
&gt;&gt;<br>
&gt;&gt; The Nak type as well as each desired type is in extended
format.<br>
&gt;<br>
&gt;OK. Can the RFC 2248bis Peer respond with an extended Nak to an offer
of a<br>
&gt;standard (1-255) type from a legacy peer? I think the answer is<br>
&gt;yes, since it is assumed that the legacy peer will ignore
everything<br>
&gt;except the first octet of the type-data (254). It will either counter
with<br>
&gt;another offer within the standard space, or send an EAP 
Failure.<br>
<br>
Actually, I think it can't. The extended Nak starts with an 8-octet, not
<br>
a 1-octet, Nak. So the type of the packet looks like 254 to the legacy
<br>
authenticator, and it won't understand it at all.<br>
<br>
If the 2284bis Peer gets a request in non-extended form, it doesn't know
if <br>
the Authenticator is legacy or 2284bis. It should therefore Nak in
non-<br>
extended form as well. If it supports authentication types in the
extended <br>
space, it can include a 254 as a desired type. If the Authenticator is
<br>
legacy, the 254 would be disregarded. If the Authenticator is 2284bis,
the <br>
presence of 254 in a Nak (even if single-octet) indicates that the Peer
is <br>
2284bis, so its next request can be in extended form. Once the Peer 
<br>
receives the extended form request, it then Nak extended types <br>
precisely, since it now knows the Authenticator is also 2284bis.<br>
<br>
A 2284bis Authenticator could take the approach of always issuing an
<br>
extended request first, even if the authentication method is a standard
<br>
one such as MD5-Challenge. If the Peer is pre-2284bis it will issue a
<br>
legacy Nak and the Authenticator will drop down to legacy operation. If
<br>
the Peer is 2284bis, it can respond with an extended Nak. This approach
<br>
may cost a round trip when the Peer is pre-2284bis, but when the Peer
<br>
is 2284bis it provides a cleanest negotiation and may save a round
trip.<br>
<br>
&gt;<br>
&gt;&gt; Nak is represented as an extended (vendor-specific) type: the
initial<br>
&gt;&gt; 254 indicates that<br>
&gt;<br>
&gt;The problem is that the state machine only allows an initial
Request<br>
&gt;(offer) of a given Type to be answered by a Response of that same
Type<br>
&gt;(offer acceptance) or a Nak (Type 3). Allowing it to be answered
by<br>
&gt;a Response of either Type 3 or 254 complicates the state
machine.<br>
<br>
I would suggest that we don't consider 254 a &quot;type&quot;. It is
really like an <br>
escape character. So if we understand &quot;type&quot; to be a code point
in a <br>
7-octet space composed of vendor-id and ordinal, and that this code 
<br>
point can be represented in either 1 octet or 8 octets (where the 1 octet
<br>
version has limited span), I think the problem goes away.<br>
<br>
&gt;<br>
&gt;&gt; Your two examples are correct, except for the omission of the
extended Nak<br>
&gt;&gt; type itself.<br>
&gt;<br>
&gt;OK. So we're talking about whether a Type of 254 or 3 is used for the
NAK<br>
&gt;packet itself. Essentially, you are defining a new NAK packet of Type
254,<br>
&gt;and I was talking about extended the old NAK packet of Type 3.<br>
<br>
Yes.<br>
<br>
&gt;<br>
&gt;&gt; An example is shown below of a Vendor-specific Nak
indicating<br>
&gt;&gt; the acceptability of two authentication types: (1)
MD5-Challenge,<br>
&gt;&gt; and (2) a hypothetical type 15 defined by a
(not-so-hypothetical)<br>
&gt;&gt; vendor with id 311:<br>
&gt;&gt;<br>
<tt>&gt;&gt;&nbsp;
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
3<br>
&gt;&gt;&nbsp; 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<br>
&gt;&gt;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&gt;&gt; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
254&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Vendor-Id = 0<br>
&gt;&gt;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&gt;&gt;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Vendor-Type = 3
(Nak)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&gt;&gt;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&gt;&gt; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
254&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Vendor-Id = 0<br>
&gt;&gt;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&gt;&gt;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Vendor-Type = 4
(MD5-Challenge)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>
&gt;&gt;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&gt;&gt; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
254&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Vendor-Id = 311<br>
&gt;&gt;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&gt;&gt;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Vendor-Type =
15&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&gt;&gt;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
</tt>&gt;<br>
&gt;Thanks.<br>
&gt;<br>
&gt;Question -- are there things that you can do by defining a new NAK
packet<br>
&gt;that you couldn't do by extending the old one? In the case given
above the<br>
&gt;functionality is similar -- but I assume that the added overhead is
also<br>
&gt;meant to provide some additional flexibility.<br>
<br>
Actually, I don't think of this as defining a new Nak packet, but
extending <br>
the interpretation of the Nak element.<br>
<br>
The purpose of the extended Nak packet is to provide backward <br>
compatibility while preserving equivalent functionality across the entire
<br>
spectrum of types.<br>
<br>
This could have be done in a number of ways; any mechanism would have
<br>
to be examined to make sure there are no avenues for misinterpretation
<br>
due to different versions of the standard being supported on Peer and
<br>
Authenticator.<br>
<br>
The mechanism of defining an extended type space that comprises <br>
the original type space seemed to me the least arbitrary, and easily
<br>
verified to be harmless to existing implementations.<br>
<br>
I think any added flexibility it provides relates to the ability of a
2284bis Peer <br>
and 2284bis Authenticator to discover that they are both indeed 2284bis,
<br>
even if they are using a standard protocol such as MD5-Challenge. If we
<br>
want to add any new features to the protocol, such as Peer response 
<br>
to EAP-Success, this could be the avenue to do this without breaking
<br>
existing implementations.<br>
<br>
Paul<br>
<br>
<div>Paul Funk</div>
<div>Funk Software, Inc.</div>
<div>617 497-6339</div>
<div>[email-masked]</div>
</html>

--=====================_180755843==_.ALT--