Subject: [eap] EAP WG last call on RFC 2284bis

From: [email-masked] (Bernard Aboba)
Date: Mon, 16 Jun 2003 05:55:38 -0700 (PDT)

This is an announcement of EAP WG last call on RFC 2284bis, prior to
sending it on to the IESG for consideration as an IETF Proposed Standard.

The draft is not yet available on the IETF archive, but should be there by
Wednesday or Thursday at the latest. Until then, it is available for
examination here:

http://www.levkowetz.com/pub/ietf/drafts/eap/draft-ietf-eap-rfc2284bis-04.e.txt

When it arrives on the archive, the  document will be available for
examination here:
http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-04.txt

EAP WG last call will last until July 7, 2003. Please send comments to
the EAP WG mailing list ([email-masked]) in the format specified on the
EAP Issues list:

http://www.drizzle.com/~aboba/EAP/eapissues.html

---

From: [email-masked] (John Vollbrecht)
Date: Mon, 16 Jun 2003 21:53:20 -0400

The document is quite good.  Thanks to all who have worked on it, including 
Henri, Bernard, and Jari among others.

Three small issues:

Issue 1

Editorial Issue: use intial key activation instead of key activation
Submitter name: John Vollbrecht
Submitter email address:[email-masked]
Date first submitted: June 16, 2003
Document: RFC2284bis
Comment type: E
Priority:  '2'
Section: 3.1 paragraph 5
Rationale/Explanation of issue: 802 key activation may be prolonged by 
authentication as well as initiated.  The text here applies to initial 
authentication.

Requested change: insert the word ", initial" between "media" and "key 
activation"

Issue 2

Description of issue:  Sequences of Methods are not allowed in untunnelled 
layer methods, but are allowed inside tunnels
Submitter name: John Vollbrecht
Submitter email address: [email-masked]
Date first submitted: June 16,2003
Document: RFC2284bis
Comment type: T
Priority:  '2'
Section: 7.4 paragraph 2

Rationale/Explanation of issue:   Security issues addressed in this section 
seem to address only what happens in an unprotected EAP method.  Section 
2.1 indicates that within a tunnel sequences may be used.

Requested change: add the word "untunnelled" between the words "permit" and 
"sequences".

Issue 3

Description of issue:  Peer policy may allow different methods for 
different   Access Points
Submitter name: John Vollbrecht
Submitter email address: [email-masked]
Date first submitted: June 16,2003
Document: RFC2284bis
Comment type: T
Priority:  '2'
Section: 7.8 Paragraph 2

Rationale/Explanation of issue:  Peers may include policy, especially when 
connecting subnets.  Additionally the same identity may have different 
permissions at different Access Points.

Requested change: In paragraph 2 make the following  2 changes noted in 
quotes below -

Within or associated with each authenticator, it is not anticipated that a 
particular named peer will support a choice of methods "for a given 
connection". This would make the peer vulnerable to attacks that negotiate 
the least secure method from among a set. Instead, for each named peer 
there SHOULD be an indication of exactly one method used to authenticate 
that peer name "at an access point". If a peer needs to make use of 
different authentication methods under different circumstances, then 
distinct identities SHOULD be employed, each of which identifies exactly 
one authentication method.

---

From: [email-masked] (Jari Arkko)
Date: Tue, 17 Jun 2003 16:10:11 +0300

John Vollbrecht wrote:
> The document is quite good.  Thanks to all who have worked on it, 

Many thanks to you as well!

> Requested change: insert the word ", initial" between "media" and "key 

I think this is right.

> Issue 2
> 
> Description of issue:  Sequences of Methods are not allowed in 
> untunnelled layer methods, but are allowed inside tunnels
> Rationale/Explanation of issue:   Security issues addressed in this 
> section seem to address only what happens in an unprotected EAP method.  
> Section 2.1 indicates that within a tunnel sequences may be used.
> 
> 
> Requested change: add the word "untunnelled" between the words "permit" 
> and "sequences".

Agree.

> Rationale/Explanation of issue:  Peers may include policy, especially 
> when connecting subnets.  Additionally the same identity may have 
> different permissions at different Access Points.
> 
> 
> Within or associated with each authenticator, it is not anticipated that 
> a particular named peer will support a choice of methods "for a given 
> connection". This would make the peer vulnerable to attacks that 
> negotiate the least secure method from among a set. Instead, for each 
> named peer there SHOULD be an indication of exactly one method used to 
> authenticate that peer name "at an access point". If a peer needs to 
> make use of different authentication methods under different 
> circumstances, then distinct identities SHOULD be employed, each of 
> which identifies exactly one authentication method.

Hmm... I don't have a warm and fuzzy feeling about this.
What if the attacker spoofs the name of the access point
to get the bidding down attack started?

--Jari

---

From: [email-masked] (John Vollbrecht)
Date: Tue, 17 Jun 2003 11:07:53 -0400

Issue three discussion below -

> > Within or associated with each authenticator, it is not anticipated
> > that  a particular named peer will support a choice of methods "for a
> > given  connection". This would make the peer vulnerable to attacks that
This is where policy must be involved.  if the attacker AP bids up, the 
authentication should go up.  If the attacker AP bids down, the 
authentication and also the rights should go down.

Additional info may be involved, depending whether the AP is wireless or 
wired.  Wireless may require Keys and a different authentication method 
than wired.

I think the idea that there should be only one id for each authentication 
method is too restrictive.  The same user should be able to get on in 
different places, with different rights, using different authentication 
methods.  The user could have different ids for each authentication method 
and try to match the id to the access type, geographic location, etc. - but 
this seems unlikely in practice.

-- John

---

From: [email-masked] (Jari Arkko)
Date: Tue, 17 Jun 2003 18:17:22 +0300

John Vollbrecht wrote:

> I think the idea that there should be only one id for each 
> authentication method is too restrictive.  The same user should be able 
> to get on in different places, with different rights, using different 
> authentication methods.  The user could have different ids for each 
> authentication method and try to match the id to the access type, 
> geographic location, etc. - but this seems unlikely in practice.

I can see your argument.

But I'm still worried that without a specific model
for what policies are possible, there'll be bidding down
problems. For instance, the AP identity does not appear to be
a good source for the policy, but link type (wired/wireless)
might be slightly better.

So, I'd rather err on the safe side and not allow such
flexibility. The downside is that it might make things
hard for some cases. But I'm not sure how typical the
per-AP or per-link type credential policies are. Do
you have any information on that? Compared to the SSID
and other information presented by the authenticator?

--Jari

---

From: [email-masked] (Henrik Levkowetz)
Date: Tue, 17 Jun 2003 19:33:54 +0200

On Mon, 16 Jun 2003 21:53:20 -0400

> Henri, Bernard, and Jari among others.

Thanks, and of course the same thanks are due to yourself, too, John!

	Henrik

-- 
  Basic research is what I'm doing when I don't know what I'm doing. 
    -- Wernher von Braun

---

From: [email-masked] (Yoshihiro Ohba)
Date: Wed, 18 Jun 2003 05:35:29 -0700

Description of issue: Lower-layer behavior for limited access
Submitter name: Yoshihiro Ohba
Submitter email address: [email-masked]
Date first submitted: June 18, 2003
Document: RFC2284bis
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.

On the other hand, the following text in section 4.2 contains 
some wording that does not seem to consistent with section 7.9.

"On the peer, once the method completes unsuccessfully (that is,
either the authenticator sends a method-specific failure indication,
or the peer decides that it does want to continue the conversation,
possibly after sending a method-specific failure indication), the peer
MUST terminate the conversation and avoid sending data on the link."

I think whether the peer avoids sending data on the link is a sort of
thing that should be described in each lower-layer protocol that
carries EAP, since this is heavily lower-layer dependent as described
in section 7.9.  In fact, if the peer avoids sending data on the link,
limited access scenario cannot be realized (though it might depend on
the definition of "link").  In sectioni 4.2, it is described that a
backend EAP server can send EAP Success when it does not need to
authenticate the peer, but how it can determine it does not need to
authenticate the peer in a roaming environment where it might be
difficult for the EAP server to know the network access policy on the
remote NAS?  I know this issue was recently discussed and section 4.2
was updated to reflect the discussion, but I still find an
inconsistency that should be resolved.

Requested change:

Remove "and avoid sending data on the link".

Thanks,
Yoshihiro Ohba

---

From: [email-masked] (John Vollbrecht)
Date: Thu, 19 Jun 2003 08:31:36 -0400

I asgree with this.  EAP should not specify behaviour on otherlayers -- John

--On Wednesday, June 18, 2003 5:35 AM -0700 Yoshihiro Ohba 
<[email-masked]> wrote:

> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap