Alan DeKok | 27 May 12:29 2009

Re: EAP Id management

Alper Yegin wrote:
> According to RFC 3748:
>
>       Since the Identifier space is unique to each session, 
>       authenticators are not restricted to only 256 simultaneous
>       authentication conversations.  Similarly, with re-authentication,
>       an EAP conversation might continue over a long period of time, and
>       is not limited to only 256 roundtrips.

  I think that statement isn't overly clear.

> This statement implies that the Identifier management extends beyond
> EAP-Success/Failure into subsequent EAP re-authentications.

  That would seem to be a valid interpretation of that sentence.
However, all AAA servers I'm aware of treat EAP sessions as finishing at
EAP-Success/Fail.

  That is, the *EAP* layer management treats re-authentication the same
as authentication.  The EAP Id's are tracked, but once an
EAP-Success/Fail is sent back, all information about "current" Id's is
discarded.

> If that’s
> true, Id of the first EAP packet after an EAP-Success (e.g., initiation
> of EAP re-auth) has to be different than the Id used with the
> EAP-Success. [Problem: EAP re-auth may take place with another
> authenticator in the case of mobility, and that authenticator would not
> know the last Id used with the previous authenticator.]

(Continue reading)

Hubert.Ertl | 27 May 12:17 2009

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


Ich bin ab  20.05.2009 nicht im Büro und bin ab 29.05.2009 wieder anwesend.

I am out of office, but will regularly check my email. On urgent matters
please leave a message on my mobile.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

Alper Yegin | 27 May 09:47 2009

EAP Id management

I hope this ML is active and people can provide feedback.

 

According to RFC 3748:

 

 

      Since the Identifier space is unique to each session,

      authenticators are not restricted to only 256 simultaneous

      authentication conversations.  Similarly, with re-authentication,

      an EAP conversation might continue over a long period of time, and

      is not limited to only 256 roundtrips.

 

 

This statement implies that the Identifier management extends beyond EAP-Success/Failure into subsequent EAP re-authentications. If that’s true, Id of the first EAP packet after an EAP-Success (e.g., initiation of EAP re-auth) has to be different than the Id used with the EAP-Success. [Problem: EAP re-auth may take place with another authenticator in the case of mobility, and that authenticator would not know the last Id used with the previous authenticator.]

 

But on the other hand, this text is not normative, and EAP State Machine RFC 4137 already ignores that by resetting currentId to "NONE" at the beginning of EAP authentication.

 

So, which one is the right way, and which one did the implementations follow?

 

I already asked few people, and need feedback from others as well.

 

Thanks in advance.

 

Alper

 

 

 

 

 

 

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap
Hubert.Ertl | 25 Nov 12:17 2008

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


Ich bin ab  24.11.2008 nicht im Büro und bin ab 27.11.2008 wieder anwesend.

I am out of office. Please leave a message on my mobile in case of urgency
or use your alternate contacts at G&D.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

Yao Zhao | 24 Nov 20:19 2008

Vulnerability in TLS-based EAP protocols

Description of issue
We found that for TLS-based EAP protcols (such as EAP-TLS, EAP-TTLS and PEAP) can be easily attacked so that the users cannot got authenticated. The attack on PEAP was implemented and tested on a large university wireless networks using PEAP.

Submitter name: Yao Zhao

Submitter email address: yzhao <at> cs.northwestern.edu

Date first submitted: Nov 24, 2008

Reference:
www.cs.northwestern.edu/~yzhao/papers/errormsg.pdf

Length description of problem:

The attack targets the TLS protocol, which is widely used in many EAP protocols such as PEAP, EAP-TLS, EAP-TTLS and EAP-FAST. Therefore, all the TLS based EAP protocols will be vulnerable to this attack.

An attacker sniffs the communication between the wireless client and the access point, inspecting the authentication procedure through the Handshake protocol of TLS. Triggered by some messages, the attacker spoofs a corresponding FATAL ALERT messages to make the TLS authentication fail. Specifically, the attacker can spoof to be either the authentication server or the client to fool the other side.

Please see more details in the pdf file provided above.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap
rfc-editor | 15 Aug 22:53 2008

RFC 5247 on Extensible Authentication Protocol (EAP) Key Management Framework


A new Request for Comments is now available in online RFC libraries.

        
        RFC 5247

        Title:      Extensible Authentication Protocol (EAP) Key 
                    Management Framework 
        Author:     B. Aboba, D. Simon,
                    P. Eronen
        Status:     Standards Track
        Date:       August 2008
        Mailbox:    bernarda <at> microsoft.com, 
                    dansimon <at> microsoft.com, 
                    pasi.eronen <at> nokia.com
        Pages:      79
        Characters: 193535
        Updates:    RFC3748

        I-D Tag:    draft-ietf-eap-keying-22.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5247.txt

The Extensible Authentication Protocol (EAP), defined in RFC 3748,
enables extensible network access authentication.  This document
specifies the EAP key hierarchy and provides a framework for the
transport and usage of keying material and parameters generated by
EAP authentication algorithms, known as "methods".  It also provides
a detailed system-level security analysis, describing the conditions
under which the key management guidelines described in RFC 4962 can
be satisfied.  [STANDARDS TRACK]

This document is a product of the Extensible Authentication Protocol Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor <at> rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

_______________________________________________
IETF-Announce mailing list
IETF-Announce <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

The IESG | 2 Jun 19:45 2008
Picon

WG Action: Conclusion of Extensible Authentication Protocol (eap)

The Extensible Authentication Protocol working group (eap) in the Internet
Area has concluded.

The IESG contact persons are Jari Arkko and Mark Townsley.

The mailing list will be closed. 

The EAP WG has been closed after it has successfully completed its
chartered work items. The mailing list will be closed soon, but its
archives will continue to exist. Given that the EMU WG has an active
discussion list, any EAP layer related matters can be taken up there. If
there are major future discussions or extensions, new lists or working
groups can be created to address those.

I would like to thank everyone involved in this effort over the years:
Bernard, all of our document editors and contributors. Thank you -- I
believe we made a big difference in improving the specifications and
real-world interoperability. EAP has been successfully deployed in large
scale, and its time to move on.

Jari Arkko
_______________________________________________
IETF-Announce mailing list
IETF-Announce <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

abhishek singh | 1 Jun 14:46 2008
Picon

http://www.ietf.org/internet-drafts/draft-abhi-eap-radius-00.txt

Hi Every One,

   I had some thoughts for secure communication between EAP and RADIUS  server. I have posted a draft for the same.

I will appreciate feedback and comments on the same.

 
Best Regards,
Abhishek Singh

The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it



_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap
The IESG | 31 May 00:31 2008
Picon

Protocol Action: 'Extensible Authentication Protocol (EAP) Key Management Framework' to Proposed Standard

The IESG has approved the following document:

- 'Extensible Authentication Protocol (EAP) Key Management Framework '
   <draft-ietf-eap-keying-22.txt> as a Proposed Standard

This document is the product of the Extensible Authentication Protocol 
Working Group. 

The IESG contact persons are Jari Arkko and Mark Townsley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-22.txt

Technical Summary

  This document specifies the EAP key hierarchy and provides a
  framework for the transport and usage of keying material generated
  by EAP authentication algorithms, known as "methods". It also 
  provides a system-level security analysis, according to the 
  principles described in "Guidance for AAA Key Management".

Working Group Summary

  Much of the WG discussion of this document centered on aspects of
  key management, including key creation, deletion, transport and
  naming. EAP usage is growing increasingly diverse, so that there
  was discussion about whether the the examples depict the issues 
  encountered in existing EAP lower layer implementations, and whether 
  the principles articulated are universal or merely true for all
  existing implementations. There was also discussion about
  the relationship between this document and "Guidance for AAA Key
  Management" which articulates principles that AAA Key Management
  solutions must satisfy to qualify for standards track publication.

Document Quality

  There are existing implementations of this document, and further    
  implementations are likely.

Personnel

  Bernard Aboba is the document shepherd. The responsible Area Director
  is Jari Arkko. No IANA expert is needed.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

Hubert.Ertl | 30 May 12:16 2008

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


Ich bin ab  26.05.2008 nicht im Büro und bin ab 02.06.2008 wieder anwesend.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

Ahmad Muhanna | 29 May 18:47 2008

This is a test, Please ignore.

Please ignore.
 

Regards,
Ahmad

 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

Gmane