headers
Bernard Aboba | 2 Aug 2003 22:14

Proposed resolution to Issue 164: Conflicting Implementation Note

The text of Issue 164 is enclosed below.  The recommendation is that
the proposed change be accepted.  Any objections?

-------------------------------------------------------------------------
Issue 164: Conflicting Implementation Note
Submitter name: Joe Salowey
Submitter email address: jsalowey <at> cisco.com
Date first submitted: 7/29/2003
Reference:
Document: RFC2284bis
Comment type: T
Priority: S
Section: 5.1
Rationale/Explanation of issue:

In section 2 [3] there is the following text
"After a suitable number of
       retransmissions, the authenticator SHOULD end the EAP
       conversation.  The authenticator MUST NOT send a Success or
       Failure packet when retransmitting or when it fails to get a
       response from the peer."

In section 5.1 there is the following text in the implementation note:

"It is suggested that the Identity Request be
 retried a minimum of 3 times before terminating the
authentication phase with a Failure reply."

This seems contradictory.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bernard Aboba | 2 Aug 2003 22:17

Proposed Resolution to Issue 163: Minor Editorial Nit

The text of issue 163 is enclosed below.  The recommendation is that the
proposed change be accepted.  Any objections?

--------------------------------------------------------------------------
Issue 163: Minor Editorial Nit
Submitter name: Lauri Tarkkala
Submitter email address: ltarkkal <at> ssh.com
Date first submitted: July 21, 2003
Reference:
http://mail.frascone.com/pipermail/public/eap/2003-July/001508.html
Document: EAP-04
Comment type: E
Priority: 2
Section:  2.1
Rationale/Explanation of issue:
Third paragraph in Section 2.1 states

"A peer MUST NOT send a Nak (legacy or expanded) in reply to a
Request, after an initial non-Nak Response has been sent.  Since
spoofed EAP Request packets may be sent by an attacker, an
authenticator receiving an unexpected Nak SHOULD silently
discard it and log the event."

and in Section 1.2 we have the definition of silently discard:

"This means the implementation discards the packet
without further processing.  The implementation
SHOULD provide the capability of logging the
event, including the contents of the silently discarded packet,
and SHOULD record the event in a statistics counter."
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bernard Aboba | 2 Aug 2003 22:28

Discussion of Issue 162: Minimum MTU Not Defined

The text of Issue 162 is enclosed below.  Here is the proposed change and
some commentary:

"Minimum MTU. The EAP layer, the EAP Identity method,
EAP Notification method and the NAK responses do NOT support
fragmentation and reassembly. "

[BA] Recommend adding EAP OTP, GTC and Challenge-MD5 to this list.

EAP methods designed originally
for use within PPP (where a 1500 byte MTU is guaranteed for
control frames [RFC1661]) also lack fragmentation and reassembly features.

[BA] It is true that the methods defined in RFC 2284 also do not support
fragmentation and reassembly.  Since we don't have specifications for
many methods that have been allocated type codes since then, it is hard to
say whether the statement above is true or not.  Certainly EAP TLS [RFC
2716] does support fragmentation.

Question: Is a 1500 byte MTU really guaranteed for control frames?  I seem
to recall situations where only a 576 octet MTU was available.  My
suggestion is that the above sentence be changed to "may lack
fragmentation and reassembly features".

"The lower layer transporting EAP MUST therefore be capable of carrying
EAP frames of up to 1400 bytes unfragmented. Note also that EAP is a
lock-step protocol, which implies a certain inefficiency when doing
fragmentation and reassembly. The lower layer therefore SHOULD
provide fragmentation and reassembly services."
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernard Aboba | 3 Aug 2003 04:24

Discussion of Issue 152: Lower layer indications

The text of Issue 152 is enclosed below.

I think the major difference between the two
approaches is for one-way methods such as EAP-MD5 Challenge.

With one-way methods a peer is ready to accept an EAP Success
after sending its Response. Since the peer does not
authenticate the authenticator it is willing to access
any network that indicates it is willing to grant access.

In this case the proposed change is for a lower layer success
indication to cause the peer to conclude that it has been granted
access, even though it had no indication from EAP that the
authenticator was willing to grant access.

This doesn't really create any new security vulnerabilities since a
one-way method is vulnerable to a spoofed EAP Success anyway.  On the
other hand, one-way methods are really only appropriate for physically
secure wired media in which the loss rate should be very low, so that I
don't think there is that much benefit to be provided.

So that the peer doesn't encounter a timeout, it probably makes sense to
have some assurance that the link is actually providing IP connectivity or
is likely to do so.

So I think we might need to revise the definition of a
"lower layer success indication" so that it is likely to
be indicative of IP connectivity (e.g. PPP NCP or IP packets)
rather than just a layer 2 frame (e.g. Reassociation Response).
(Continue reading)

Permalink | Reply | 4 comments |
headers
Bernard Aboba | 3 Aug 2003 04:42

Proposed resolution to Issue 151: EAP-04 comments

The text of Issue 151 is enclosed below.  Overall, these changes look good
and the proposed resolution is to accept them, with the exception of the
change relating to "granting access."  Since only some methods do key
derivation, the existing paragraph seems to cover more cases and the
proposed text does not really substitute for it.

Here are the proposed fixes:

In Section 2, change:

"ince EAP is a peer-to-peer protocol, an
independent and simultaneous authentication may take place in
the reverse direction."

To:

"Since EAP is a peer-to-peer protocol, an independent and
simultaneous authentication may take place in the reverse
direction (depending on the capabilities of the lower layer)."

In Section 4.2, change:

"Success or Failure packets MUST NOT be sent by
an EAP authenticator prior to completion of the final round
of a given method. A peer EAP implementation receiving a
Success or Failure packet prior to completion of the method
in progress MUST silently discard it."

To:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bernard Aboba | 3 Aug 2003 04:47

Proposed resolution to Issue 150: Lower Layer Behavior for Limited Access

The text of Issue 150 is enclosed below.

I don't think that the intent of section 7.9 is to make the interpretation
of EAP Failure implementation dependent -- this is the kind of thing that
needs to be standardized in order for the protocol to be interoperable.

Allowing the peer to activate the link after receiving an indication
that the authenticator is not granting access seems dangerous because it
would be likely to either open the door to rogue authenticators or to
timeouts where the peer would attempt to obtain an IP address and fail,
leaving the user in limbo.

My recommendation is that this change be rejected.

------------------------------------------------------------------
Issue 150: Lower Layer Behavior for Limited Access
Submitter name: Yoshihiro Ohba
Submitter email address: yohba <at> tari.toshiba.com
Date first submitted: June 18, 2003
Reference:
Document: EAP-04
Comment type: T
Priority: 1
Section: 4.2
Rationale/Explanation of issue:

Text in section 7.9 allows limited access for peer after completion of
EAP authentication with failure, with stating that the interaction of
EAP with lower layers are highly implementation dependent.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bernard Aboba | 3 Aug 2003 05:08

Issue 165: Applicability statement

Issue 165: Applicability Statement
Submitter name: Bernard Aboba
Submitter email address: aboba <at> internaut.com
Date first submitted: 8/2/2003
Reference:
Document: RFC2284bis
Comment type: T
Priority: S
Section: 1.4
Rationale/Explanation of issue:

EAP needs an applicability statement so that it is clear when it is
appropriate and inappropriate to use it.

Insert the following section:

1.4 Applicability

EAP is an authentication framework for use in situations, such as network
access, in which the IP layer connectivity may not be available.
Since the goal of EAP is to support authentication without requiring
IP connectivity, it provides just enough support for the
reliable transport of authentication protocols, and no more. While EAP
provides support for retransmission, it assumes ordering guarantees
provided by the lower layer, so that out of order reception is not
supported. EAP itself does not support fragmentation; however,
EAP methods may provide this support.

Since EAP does not support fragmentation as in IP, or an efficient
reliable transport service as in TCP [RFC793] or SCTP [RFC2960],
(Continue reading)

Permalink | Reply | 5 comments |
headers
Hubert.Ertl | 3 Aug 2003 05:42

Hubert Ertl/GDM/GuD is out of the office.


Ich werde ab  01.08.2003 nicht im Büro sein. Ich kehre zurück am
18.08.2003.

I will read my email during my absence and will  respond to your message
when I return on August 18th.
Permalink | Reply | 0 comments |
headers
Bernard Aboba | 3 Aug 2003 05:22

Re: Issue 142 suggestion: syntax for network info hint in Type-Data field of Identity-Request

There are a few issues with the proposed approach.

a. This is not what current implementations do, and RFC 2284bis is
primarily about documenting existing behavior.  By going with XML we would
be creating two distinct and non-interoperable "hint" specifications, and
that seems like a bad idea.

b. Given that the Identity method doesn't support fragmentation, we are
limited by the minimum MTU (see Issue 162).  Given those limitations it
would seem that the additional overhead of XML would be potentially
problematic.

-----------------------------------------------------------------------
In Issue 142, Bernard has suggested that specification of the Type-Data
field data of Identity-Request after the nul character should include:

a) An ABNF describing the grammar for the parameters and values;
b) IANA considerations for allocation of parameters and values.

Here is a suggestion for dealing with points a) and b).

Suppose we use XML syntax instead of the previously proposed syntax for
this data.  IANA considerations can  be dealt with using the XML
namespace mechanism.  Here is an example:

display-string\0<?xml><NetInfo xmlns=3D"urn:ietf.org:EAP:Netinfo"
networkid=3D"SomeSSID" nasid=3D"SomeNASName"  portid=3D"123" />

The schema associated with urn:ietf.org:EAP:Netinfo would define the
attributes networkid, nasid, portid,  and whatever else might be
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yoshihiro Ohba | 3 Aug 2003 06:22

Re: Proposed resolution to Issue 150: Lower Layer Behavior for Limited Access

I believe that the behavior on whether to "avoid sending data on the
link or not" should be better specified in each EAP transport
protocol, not in RFC2284 bis.  I agree that when IEEE 802.1X is used
the supplicant must avoid sending data on the link if EAP
authentication fails, because it is the port-based access control
model IEEE 802.1X defines.  On the other hand, when PANA is used as
the EAP transport, the PANA client may already obtain an IP address
and is using the link (with a limited access) before EAP
authentication occurs and thus "avoid sending data on the link" for
the link already in use does not make sense.  

The suggested change is actually needed for PANA to support a scenario
described in section 4.6. "Limited free access" of
draft-ietf-pana-usage-scenarios-06.txt which is now in the IESG review
after completing WGLC.

EAP is an authentication protocol but "avoid sending data on the link"
(which is a task of access control) is beyond the task of
authentication protocol, thus the text should not be included in
RFC2284bis.

Yoshihiro Ohba

On Sat, Aug 02, 2003 at 07:47:08PM -0700, Bernard Aboba wrote:
> The text of Issue 150 is enclosed below.
> 
> I don't think that the intent of section 7.9 is to make the interpretation
> of EAP Failure implementation dependent -- this is the kind of thing that
> needs to be standardized in order for the protocol to be interoperable.
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane