Subject: [eap] Re: Proposed resolution of issue #41

From: [email-masked] (Bernard Aboba)
Date: Sat, 18 Jan 2003 22:16:16 -0800 (PST)

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

OK. James has suggested that could include a Nak packet with a single Type
value of 0, to indicate no alternative. Would it also be possible for such
a legacy Nak to include more than one Type?

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

OK on the 8-octet format for Type-Data. However, the structure of the Nak
packet itself is defined in RFC 2284:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |  Type-Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Code = 2 (Response)
Type = 3 (Nak)

Are you proposing to change the format of the Nak packet?

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

Yes, within the new Nak, the 8-octet format would be used within the
Type-Data field:

    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                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Vendor-Type                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Is this right?

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

Are you saying that the legacy Nak has Type field =3, and Type-Data equal
to one or more Type values? Note that James has suggested reserving the
Type value of 0 to mean "no alternative".

> This type of Nak provides backward compatibility for peers that
> implement RFC2284 or earlier.

Yes.

> >So a NAK with a Type=3 in the data field is not legal in a legacy
> >implementation.
>
> 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.

OK.

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

OK. That makes sense.

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

I think this is where I am losing you. It would probably help to show all
the fields of the EAP packet. For example, an extended Nak proposing
two alternative Types, both within the IETF standard space would look
like this, 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Code (2)    |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type (3)    |    254        |        Vendor-Id (0)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   VID (0)     |               Vendor-Type                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    V-Type     |               Vendor-Id (0)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Vendor-Type                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

OK. Is the above example now correct?

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

Isn't this represented above by the "254" in the first octet of the
Type-Data field?

> 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
>  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      |                 Vendor-Id = 0
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                       Vendor-Type = 3 (Nak)                   |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |      254      |                 Vendor-Id = 0
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                       Vendor-Type = 4 (MD5-Challenge)         |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |      254      |                 Vendor-Id = 311
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                       Vendor-Type = 15                        |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

OK. This is more clear.

Question: Why the need for additional "254" octets after the first
one? Is this just to maintain alignment? Otherwise, I think we're
in agreement.

---

From: [email-masked] (Paul Funk)
Date: Mon, 20 Jan 2003 01:28:31 -0500

--=====================_87688656==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

>a legacy Nak to include more than one Type?

A legacy 2284 client would always Nak with a single type. 2284 says Nak
MUST have 1 data byte, though it also says that a Nak MAY offer an
alternative (implying that not proposing a type is legal). But I'm betting 
that
2284 implementations always include exactly one type in a Nak; and if they
don't have type to propose they just abandon the authentication.

A new implementation, according to the 2284bis draft, could include multiple
types in a Nak, whether the Nak is single-byte or extended. If the server is
2284 and the client is bis, the client could send multiple types in a single-
byte Nak; the server would either (a) ignore all but the first, or (b) 
reject the
message. I think most servers will do (a), which is benign. But this means
that if the server can't accommodate the first type in the client's Nak, it
may challenge with a type that wasn't in the client's list at all, so the 
client
should be prepared for this and not deem it an error.

>packet itself is defined in RFC 2284:

No.

The legacy Nak format is unchanged.

However, there is an additional Nak format, where the Nak itself and all
desired types are in extended (8-octet) format. Only bis servers will
understand the new format.

A client should only send the new format to a server that it knows is a bis
server. The way it would know is if the server used an extended type in a
request. If a client wants an extended type but doesn't know if the server is
bis, it would first do a single-byte Nak asking for 254. If the server then 
issues
a request with an extended type, it may or may not be the type the client
wants. It it's not, the client would then respond with an extended Nak for the
exact type it wanted.

Yes.

>Type value of 0 to mean "no alternative".

Yes. As I mentioned above, a 2284 Nak would not have more than one
type values. Using type = 0 is a good idea; legacy servers should handle
it correctly.

>two alternative Types, both within the IETF standard space would look

No. The above would look to a server like a single-byte Nak with a bunch of
single-byte desired types following it, the first of which is a 254. 
There's no way
to know that these are extended types except by noticing that octets are 
repeated.

The 254 is supposed to be in the first position, where the 3 is.

Here's the example shown below, but also showing the EAP header, so this is 
the
full packet. It is a Nak, proposing MD5-Challenge and type 15 from vendor 311:

  0                   1                   2                   3
|   Code = 2    |  Identifier   |       Length  = 
28                            |
|      254      |                 Vendor-Id = 
0                                  |
|      254      |                 Vendor-Id = 
0                                  |
|      254      |                 Vendor-Id = 
311                              |

>Isn't this represented above by the "254" in the first octet of the

I'm not sure if which bit diagram you are referring to, so I won't hazard 
an answer. If this
is still an open question, email me again with the bit diagram .

>one? Is this just to maintain alignment? Otherwise, I think we're

Strictly speaking, they're not necessary, since the fact that this is an
extended Nak requires that all types are in extended format. So it could
be defined either way. I think the alignment issue is more important for
neatness in the bit diagrams in the RFC than for ease of coding. Mainly,
I think that it will be clearer if extended types always are 8 octets, rather
than sometimes 8 octets and sometimes 7.

Paul

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

<html>
<body>
At 10:16 PM 1/18/2003 -0800, Bernard Aboba wrote:<br>
<blockquote type=cite class=cite cite>&gt; &gt;I assume that if the
authenticator begins with a V-S type (254), then the<br>
&gt; &gt;legacy peer would NAK with a single type within the standard
space<br>
&gt; &gt;(4-192).<br>
&gt;<br>
&gt; Correct.<br><br>
OK. James has suggested that could include a Nak packet with a single
Type<br>
value of 0, to indicate no alternative. Would it also be possible for
such<br>
a legacy Nak to include more than one Type?</blockquote><br>
A legacy 2284 client would always Nak with a single type. 2284 says Nak
<br>
MUST have 1 data byte, though it also says that a Nak MAY offer an <br>
alternative (implying that not proposing a type is legal). But I'm
betting that <br>
2284 implementations always include exactly one type in a Nak; and if
they <br>
don't have type to propose they just abandon the 
authentication.<br><br>
A new implementation, according to the 2284bis draft, could include
multiple <br>
types in a Nak, whether the Nak is single-byte or extended. If the server
is <br>
2284 and the client is bis, the client could send multiple types in a
single-<br>
byte Nak; the server would either (a) ignore all but the first, or (b)
reject the <br>
message. I think most servers will do (a), which is benign. But this
means <br>
that if the server can't accommodate the first type in the client's Nak,
it <br>
may challenge with a type that wasn't in the client's list at all, so the
client <br>
should be prepared for this and not deem it an error.<br><br>
<br>
<blockquote type=cite class=cite cite>&gt; The 2284bis Peer would Nak
with a mixture of standard and<br>
&gt; extended types. However, all types (including the Nak itself)<br>
&gt; would be in extended (8-octet) format.<br><br>
OK on the 8-octet format for Type-Data. However, the structure of the
Nak<br>
packet itself is defined in RFC 2284:<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; Code&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; Identifier&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; Type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; Type-Data ...<br>
&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<br><br>
Code = 2 (Response)<br>
Type = 3 (Nak)<br><br>
Are you proposing to change the format of the Nak
packet?</blockquote><br>
No.<br><br>
The legacy Nak format is unchanged.<br><br>
However, there is an additional Nak format, where the Nak itself and all
<br>
desired types are in extended (8-octet) format. Only bis servers will
<br>
understand the new format. <br><br>
A client should only send the new format to a server that it knows is a
bis <br>
server. The way it would know is if the server used an extended type in a
<br>
request. If a client wants an extended type but doesn't know if the
server is <br>
bis, it would first do a single-byte Nak asking for 254. If the server
then issues <br>
a request with an extended type, it may or may not be the type the client
<br>
wants. It it's not, the client would then respond with an extended Nak
for the <br>
exact type it wanted.<br><br>
<br><br>
<blockquote type=cite class=cite cite>&gt; The distinction between
standard and extended types sort of<br>
&gt; disappears in this proposal. The extended format is a superset of
the<br>
&gt; single-octet format, and includes all single-octet types. All
single-octet<br>
&gt; types (including Identity, Notification and Nak) map into the
extended<br>
&gt; format with Vendor-Id of 0.<br><br>
Yes, within the new Nak, the 8-octet format would be used within 
the<br>
Type-Data field:<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; Type=254&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;&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;
|<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br><br>
Is this right?</blockquote><br><br>
Yes.<br><br>
<br><br>
<blockquote type=cite class=cite cite>&gt; It would. My text is
misleading. How about this:<br>
&gt;<br>
&gt; The Legacy Nak, consisting of a single octet of value 3<br>
&gt; followed by one or more single-octet Authentication Types<br>
&gt; of value 4 or above, is used to reject Vendor-specific<br>
&gt; requests entirely.<br><br>
Are you saying that the legacy Nak has Type field =3, and Type-Data
equal<br>
to one or more Type values? Note that James has suggested reserving
the<br>
Type value of 0 to mean &quot;no alternative&quot;.</blockquote><br>
Yes. As I mentioned above, a 2284 Nak would not have more than one <br>
type values. Using type = 0 is a good idea; legacy servers should handle
<br>
it correctly.<br><br>
<br>
<blockquote type=cite class=cite cite>&gt; This type of Nak provides
backward compatibility for peers that<br>
&gt; implement RFC2284 or earlier.<br><br>
Yes.<br><br>
&gt; &gt;So a NAK with a Type=3 in the data field is not legal in a
legacy<br>
&gt; &gt;implementation.<br>
&gt;<br>
&gt; Correct. My intent was that a Legacy Nak is an ordinary Nak
that<br>
&gt; existing pre-2284bis Peer implementations would issue. A
2284bis<br>
&gt; Authenticator, upon receiving a Legacy Nak in response to an
extended<br>
&gt; (254) type, would recognize that the Peer doesn't support 2284bis.
It<br>
&gt; would therefore interpret the Nak according to the pre-2284bis
rules, and<br>
&gt; would desist from offering any other extended authentication types
during<br>
&gt; that session.<br><br>
OK.<br><br>
&gt; The idea here is that when a 2284bis Peer wants to Nak a
2284bis<br>
&gt; Authenticator's extended (v-s) type, it uses extended types
instead<br>
&gt; of single-octet types.<br><br>
OK. That makes sense.<br><br>
&gt; The Nak type as well as each desired type is in extended
format.<br>
&gt;<br>
&gt; So, the first 8 octets above are interpreted as type Nak, thus
indicating that<br>
&gt; this is a Nak response packet. Instead of a single octet of value 3,
the Nak is<br>
&gt; represented as an extended (vendor-specific) type: the initial 254
indicates<br>
&gt; that this is an extended type, the Vendor-Id of 0 indicates it is a
type from the<br>
&gt; IANA space, and the Vendor-Type of 3 indicates it is a Nak.<br>
&gt;<br>
&gt; The Desired Types that follow are a list of one or more 8-octet
extended<br>
&gt; authentication types that the Peer is willing to use.<br>
&gt;<br>
&gt; Each individual desired type has its own Vendor-Id - 0, 311, 1411,
etc.<br><br>
I think this is where I am losing you. It would probably help to show
all<br>
the fields of the EAP packet. For example, an extended Nak 
proposing<br>
two alternative Types, both within the IETF standard space would
look<br>
like this, 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; Code (2)&nbsp;&nbsp;&nbsp; |&nbsp;
Identifier&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; |&nbsp;&nbsp; Type (3)&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;
254&nbsp;&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; |<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; |&nbsp;&nbsp; VID (0)&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;
|<br>
&nbsp;&nbsp;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; V-Type&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&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;
|<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;
Vendor-Type&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>
&gt; There is a typo in my original example, which may be causing
confusion. The<br>
&gt; single octet &quot;4&quot; should be a &quot;254&quot;.<br><br>
OK. Is the above example now correct?</blockquote><br>
No. The above would look to a server like a single-byte Nak with a bunch
of <br>
single-byte desired types following it, the first of which is a 254.
There's no way <br>
to know that these are extended types except by noticing that octets are
repeated. <br><br>
The 254 is supposed to be in the first position, where the 3 
is.<br><br>
Here's the example shown below, but also showing the EAP header, so this
is the <br>
full packet. It is a Nak, proposing MD5-Challenge and type 15 from vendor
311:<br><br>
<tt>&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; Code = 2&nbsp;&nbsp;&nbsp; |&nbsp; Identifier&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Length</tt>&nbsp; =
28&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; 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><br>
</tt><blockquote type=cite class=cite cite>&gt; Your two examples are
correct, except for the omission of the extended Nak<br>
&gt; type itself.<br><br>
Isn't this represented above by the &quot;254&quot; in the first octet of
the<br>
Type-Data field?</blockquote><br>
I'm not sure if which bit diagram you are referring to, so I won't hazard
an answer. If this <br>
is still an open question, email me again with the bit diagram 
.<br><br>
<br>
<blockquote type=cite class=cite cite>&gt; Here's an improved version of
my proposed text with example, that includes both<br>
&gt;<br>
&gt; 0 and non-0 Vendor-Ids, fixes the typo, and adds some gloss to the
type<br>
&gt; numbers:<br>
&gt;<br>
&gt; An example is shown below of a Vendor-specific Nak indicating<br>
&gt; the acceptability of two authentication types: (1)
MD5-Challenge,<br>
&gt; and (2) a hypothetical type 15 defined by a
(not-so-hypothetical)<br>
&gt; vendor with id 311:<br>
&gt;<br>
&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;&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;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&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;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&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;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&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;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&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;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&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;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&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;
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br><br>
<br>
OK. This is more clear.<br><br>
Question: Why the need for additional &quot;254&quot; octets after the
first<br>
one? Is this just to maintain alignment? Otherwise, I think we're<br>
in agreement. </blockquote><br>
Strictly speaking, they're not necessary, since the fact that this is an
<br>
extended Nak requires that all types are in extended format. So it could
<br>
be defined either way. I think the alignment issue is more important for
<br>
neatness in the bit diagrams in the RFC than for ease of coding. Mainly,
<br>
I think that it will be clearer if extended types always are 8 octets,
rather <br>
than sometimes 8 octets and sometimes 7.<br><br>
Paul<br><br>
</body>
</html>

--=====================_87688656==.ALT--

---

From: [email-masked] (Bernard Aboba)
Date: Mon, 20 Jan 2003 23:12:59 -0800 (PST)

> don't have type to propose they just abandon the authentication.

That seems to be the favored interpretation.

> should be prepared for this and not deem it an error.

Yes. But this could also happen when both client and server are 2284
implementations, no?

OK.

> request.

Yes.

> If a client wants an extended type but doesn't know if the server is

Yes, this makes sense.

> Yes.

OK. I think we're getting closer. Can you take a look at the text proposed
for resolution of issue 41 (the message after the one you replied to) and
send corrections?

OK.

> |   Code = 2    |  Identifier   |       Length  = 28            |
> |      254      |                 Vendor-Id = 0                 |
> |      254      |                 Vendor-Id =  0                |
> |      254      |                 Vendor-Id =311                |

I think I understand this now. You are using Type=254 both for
Vendor-Specific *and* for Nak itself.

> than sometimes 8 octets and sometimes 7.

I think I understand the format of the Type-Data field, but not the use of
254 for the Type itself, instead of 3 for Nak.