[Emu] Protocol Action: 'Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)' to Proposed Standard (draft-ietf-emu-aka-pfs-12.txt)

[The IESG]

The IESG has approved the following document:
- 'Forward Secrecy for the Extensible Authentication Protocol Method for
   Authentication and Key Agreement (EAP-AKA' FS)'
  (draft-ietf-emu-aka-pfs-12.txt) as Proposed Standard

This document is the product of the EAP Method Update Working Group.

The IESG contact persons are Paul Wouters and Deb Cooley.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/





Technical Summary

 This document updates RFC 9048, the improved Extensible Authentication 
Protocol Method for 3GPP Mobile Network Authentication and Key Agreement 
(EAP-AKA'), with an optional extension providing ephemeral key exchange. 
Similarly, this document also updates the earlier version of the EAP-AKA' 
specification in RFC 5448. The extension EAP-AKA' Forward Secrecy (EAP-AKA' 
FS), when negotiated, provides forward secrecy for the session keys generated 
as a part of the authentication run in EAP-AKA'. This prevents an attacker who 
has gained access to the long-term key from obtaining session keys established 
in the past, assuming these have been properly deleted. In addition, EAP-AKA' 
FS mitigates passive attacks (e.g., large scale pervasive monitoring) against 
future sessions. This forces attackers to use active attacks instead.

Working Group Summary

 This document reflects strong consensus from members of the working group
interested in improving the EAP-AKA' method. There were zero objections raised
to moving this work forward.

Document Quality

There is at least one closed-source implementation of this specification. The
authors have indicated business interest in implementing this specification in
the near future.

This document is built on AKA, but it does not modify AKA. 3GPP, which
specifies AKA and uses the underlying RFC 5448 and 9048, have seen this
work and provided feedback.

Personnel

  Document Shepherd: Peter Yee
  Responsible AD: Paul Wouters

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Last Call: (Tunnel Extensible Authentication Protocol (TEAP) Version 1) to Proposed Standard

[The IESG]

The IESG has received a request from the EAP Method Update WG (emu) to
consider the following document: - 'Tunnel Extensible Authentication Protocol
(TEAP) Version 1'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2024-03-11. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   This document defines the Tunnel Extensible Authentication Protocol
   (TEAP) version 1.  TEAP is a tunnel-based EAP method that enables
   secure communication between a peer and a server by using the
   Transport Layer Security (TLS) protocol to establish a mutually
   authenticated tunnel.  Within the tunnel, TLV objects are used to
   convey authentication-related data between the EAP peer and the EAP
   server.  This document obsoletes RFC 7170.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-emu-rfc7170bis/



No IPR declarations have been submitted directly on this I-D.





___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Last Call: (Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)) to Proposed Standard

[The IESG]

The IESG has received a request from the EAP Method Update WG (emu) to
consider the following document: - 'Forward Secrecy for the Extensible
Authentication Protocol Method for
   Authentication and Key Agreement (EAP-AKA' FS)'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2024-03-06. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   This document updates RFC 9048, the improved Extensible
   Authentication Protocol Method for 3GPP Mobile Network Authentication
   and Key Agreement (EAP-AKA'), with an optional extension providing
   ephemeral key exchange.  Similarly, this document also updates the
   earlier version of the EAP-AKA' specification in RFC 5448.  The
   extension EAP-AKA' Forward Secrecy (EAP-AKA' FS), when negotiated,
   provides forward secrecy for the session keys generated as a part of
   the authentication run in EAP-AKA'.  This prevents an attacker who
   has gained access to the long-term key from obtaining session keys
   established in the past, assuming these have been properly deleted.
   In addition, EAP-AKA' FS mitigates passive attacks (e.g., large scale
   pervasive monitoring) against future sessions.  This forces attackers
   to use active attacks instead.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/


The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/3097/
   https://datatracker.ietf.org/ipr/3098/



The document contains these normative downward references.
See RFC 3967 for additional information: 
rfc4187: Extensible Authentication Protocol Method for 3rd Generation 
Authentication and Key Agreement (EAP-AKA) (Informational - Internet 
Engineering Task Force (IETF))
rfc5448: Improved Extensible Authentication Protocol Method for 3rd 
Generation Authentication and Key Agreement (EAP-AKA') (Informational - 
Internet Engineering Task Force (IETF))
rfc7624: Confidentiality in the Face of Pervasive Surveillance: A Threat 
Model and Problem Statement (Informational - Internet Architecture Board (IAB))
rfc9048: Improved Extensible Authentication Protocol Method for 3GPP Mobile 
Network Authentication and Key Agreement (EAP-AKA') (Informational - Internet 
Engineering Task Force (IETF))




___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Last Call: (Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)) to Informational RFC

[The IESG]

The IESG has received a request from the EAP Method Update WG (emu) to
consider the following document: - 'Forward Secrecy for the Extensible
Authentication Protocol Method for
   Authentication and Key Agreement (EAP-AKA' FS)'
   as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2023-08-01. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   Many different attacks have been reported as part of revelations
   associated with pervasive surveillance.  Some of the reported attacks
   involved compromising the smart card supply chain, such as attacking
   Universal Subscriber Identity Module (USIM) card manufacturers and
   operators in an effort to compromise long-term keys stored on these
   cards.  Since the publication of those reports, manufacturing and
   provisioning processes have received much scrutiny and have improved.
   However, resourceful attackers are always a cause for concern.
   Always assuming a breach, such as long-term key compromise, and
   minimizing the impact of breach are essential zero trust principles.

   This document updates RFC 9048, the improved Extensible
   Authentication Protocol Method for 3GPP Mobile Network Authentication
   and Key Agreement (EAP-AKA'), with an optional extension providing
   ephemeral key exchange.  Similarly, this document also updates the
   earlier version of the EAP-AKA' specification in RFC 5448.  The
   extension EAP-AKA' Forward Secrecy (EAP-AKA' FS), when negotiated,
   provides forward secrecy for the session keys generated as a part of
   the authentication run in EAP-AKA'.  This prevents an attacker who
   has gained access to the long-term key from obtaining session keys
   established in the past, assuming these have been properly deleted.
   In addition, EAP-AKA' FS mitigates passive attacks (e.g., large scale
   pervasive monitoring) against future sessions.  This forces attackers
   to use active attacks instead.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/


The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/3097/
   https://datatracker.ietf.org/ipr/3098/






___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Last Call: (Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)) to Informational RFC

[The IESG]

The IESG has received a request from the EAP Method Update WG (emu) to
consider the following document: - 'Forward Secrecy for the Extensible
Authentication Protocol Method for
   Authentication and Key Agreement (EAP-AKA' FS)'
   as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2023-03-13. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   Many different attacks have been reported as part of revelations
   associated with pervasive surveillance.  Some of the reported attacks
   involved compromising the smart card supply chain, such as attacking
   SIM card manufacturers and operators in an effort to compromise
   shared secrets stored on these cards.  Since the publication of those
   reports, manufacturing and provisioning processes have gained much
   scrutiny and have improved.  However, the danger of resourceful
   attackers for these systems is still a concern.  Always assuming
   breach such as key compromise and minimizing the impact of breach are
   essential zero-trust principles.

   This specification updates RFC 9048, the improved Extensible
   Authentication Protocol Method for 3GPP Mobile Network Authentication
   and Key Agreement (EAP-AKA'), with an optional extension.  Similarly,
   this specification also updates the earlier version of the EAP-AKA'
   specification in RFC 5448.  The extension, when negotiated, provides
   Forward Secrecy for the session key generated as a part of the
   authentication run in EAP-AKA'.  This prevents an attacker who has
   gained access to the long-term pre-shared secret in a Subscriber
   Identity Module (SIM) card from being able to decrypt any past
   communications.  In addition, if the attacker stays merely a passive
   eavesdropper, the extension prevents attacks against future sessions.
   This forces attackers to use active attacks instead.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/


The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/3097/
   https://datatracker.ietf.org/ipr/3098/






___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Protocol Action: 'TLS-based EAP types and TLS 1.3' to Proposed Standard (draft-ietf-emu-tls-eap-types-13.txt)

[The IESG]

The IESG has approved the following document:
- 'TLS-based EAP types and TLS 1.3'
  (draft-ietf-emu-tls-eap-types-13.txt) as Proposed Standard

This document is the product of the EAP Method Update Working Group.

The IESG contact persons are Paul Wouters and Roman Danyliw.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-tls-eap-types/





Technical Summary

   EAP-TLS (RFC 5216) has been updated for TLS 1.3 in RFC 9190.  Many
   other EAP types also depend on TLS, such as EAP-FAST (RFC 4851), EAP-
   TTLS (RFC 5281), TEAP (RFC 7170), and possibly many vendor specific
   EAP methods.  This document updates those methods in order to use the
   new key derivation methods available in TLS 1.3.  Additional changes
   necessitated by TLS 1.3 are also discussed.

Working Group Summary

   This document reflects strong consensus from members of the working group
   interested in TLS EAP types. Consensus was in general strong. There are
   areas where there is less implementation experience, but no objection to
   moving forward

   During IETF LC, it was noted an update was needed to the TEAP text to match
   RFC7170bis. This was announced to the WG list to verify no one objects to 
this
   late change.
   
Document Quality

   A number of vendors are looking to implement this specification. There have
   already been interoperable implementations for most of the methods in the
   document.   EAP-FAST and TEAP are a little behind in implementation.

  
Personnel

   Document Shepherd: Joseph A. Salowey
   Responsible Area Director: Paul Wouters

   The IANA Expert(s) for the registries in this document are Yoav Nir, Rich 
Salz, Nick Sullivan

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] EAP Method Update (emu) WG Interim Meeting Cancelled (was 2023-01-18)

[IESG Secretary]

The EAP Method Update (emu) virtual 
interim meeting for 2023-01-18 from 09:00 to 10:00 America/Los_Angeles
has been cancelled.





___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Last Call: (TLS-based EAP types and TLS 1.3) to Proposed Standard

[The IESG]

The IESG has received a request from the EAP Method Update WG (emu) to
consider the following document: - 'TLS-based EAP types and TLS 1.3'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2023-01-27. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

   EAP-TLS (RFC 5216) has been updated for TLS 1.3 in RFC 9190.  Many
   other EAP types also depend on TLS, such as EAP-FAST (RFC 4851), EAP-
   TTLS (RFC 5281), TEAP (RFC 7170), and possibly many vendor specific
   EAP methods.  This document updates those methods in order to use the
   new key derivation methods available in TLS 1.3.  Additional changes
   necessitated by TLS 1.3 are also discussed.


The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-emu-tls-eap-types/


No IPR declarations have been submitted directly on this I-D.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] EAP Method Update (emu) WG Virtual Meeting: 2023-01-18

[IESG Secretary]

The EAP Method Update (emu) WG will hold
a virtual interim meeting on 2023-01-18 from 09:00 to 10:00 America/Los_Angeles 
(17:00 to 18:00 UTC).

Agenda:
1. TEAP Errata
2. TEAP Revision

Information about remote participation:
https://meetings.conf.meetecho.com/interim/?short=1d018478-8fa8-4808-82a0-747466a643fc

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] EAP Method Update (emu) WG Virtual Meeting: 2023-01-11

[IESG Secretary]

The EAP Method Update (emu) WG will hold
a virtual interim meeting on 2023-01-11 from 09:00 to 10:00 America/Los_Angeles 
(17:00 to 18:00 UTC).

Agenda:
1. TEAP Errata
2. TEAP Revision

Information about remote participation:
https://meetings.conf.meetecho.com/interim/?short=18b67a69-dc0a-498c-90b5-4ddd9dbfb5e4

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] EAP Method Update (emu) WG Virtual Meeting: 2023-01-04

[IESG Secretary]

The EAP Method Update (emu) WG will hold
a virtual interim meeting on 2023-01-04 from 09:00 to 10:00 America/Los_Angeles 
(17:00 to 18:00 UTC).

Agenda:
1. TEAP Errata
2. TEAP Revision

Information about remote participation:
https://meetings.conf.meetecho.com/interim/?short=1756daa0-b496-469f-aed3-1a61158f90b6

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Protocol Action: 'Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3)' to Proposed Standard (draft-ietf-emu-eap-tls13-21.txt)

[The IESG]

The IESG has approved the following document:
- 'Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3)'
  (draft-ietf-emu-eap-tls13-21.txt) as Proposed Standard

This document is the product of the EAP Method Update Working Group.

The IESG contact persons are Benjamin Kaduk and Roman Danyliw.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/





Technical Summary


   The Extensible Authentication Protocol (EAP), defined in RFC 3748,
   provides a standard mechanism for support of multiple authentication
   methods.  This document specifies the use of EAP-Transport Layer
   Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible
   with existing implementations of EAP-TLS.  TLS 1.3 provides
   significantly improved security, privacy, and reduced latency when
   compared to earlier versions of TLS.  EAP-TLS with TLS 1.3 (EAP-TLS
   1.3) further improves security and privacy by always providing
   forward secrecy, never disclosing the peer identity, and by mandating
   use of revocation checking.  This document also provides guidance on
   authentication, authorization, and resumption for EAP-TLS in general
   (regardless of the underlying TLS version used).  This document
   updates RFC 5216.

Working Group Summary

The document had a lot of review and discussion.  There is in general good 
consensus for moving the document forward.  Towards the end of the WG 
discussion, an additional consensus call was needed to agree produce the 
normative language on OCSP usage.

This document was sent for IESG review in February 2021.  IESG review uncovered 
a design issue 
(https://mailarchive.ietf.org/arch/msg/emu/3ZFWAx0of-67P6yhtMIdmx9BLNs/) which 
sent the document back to the WG.  This document was updated, sent through WG 
and IETF LC and is now returning again to the IESG.

Document Quality

Much of the discussion on the list was based on comments from implemented of 
the previous version of the protocol or the proposed version of the protocol. 

At least two public implementations of the protocol are available:

wpa_supplicant - https://w1.fi/cgit/hostap/ 

free radius - https://github.com/FreeRADIUS/freeradius-server

Personnel

Document Shepherd - Joe Salowey

Responsible AD - Roman Danyliw

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Protocol Action: 'Nimble out-of-band authentication for EAP (EAP-NOOB)' to Proposed Standard (draft-ietf-emu-eap-noob-06.txt)

[The IESG]

The IESG has approved the following document:
- 'Nimble out-of-band authentication for EAP (EAP-NOOB)'
  (draft-ietf-emu-eap-noob-06.txt) as Proposed Standard

This document is the product of the EAP Method Update Working Group.

The IESG contact persons are Benjamin Kaduk and Roman Danyliw.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/





Technical Summary

   The Extensible Authentication Protocol (EAP) provides support for
   multiple authentication methods.  This document defines the EAP-NOOB
   authentication method for nimble out-of-band (OOB) authentication and
   key derivation.  The EAP method is intended for bootstrapping all
   kinds of Internet-of-Things (IoT) devices that have no pre-configured
   authentication credentials.  The method makes use of a user-assisted
   one-directional OOB message between the peer device and
   authentication server to authenticate the in-band key exchange.  The
   device must have an input or output interface, such as a display,
   microphone, speaker or blinking light, which can send or receive
   dynamically generated messages of tens of bytes in length.

Working Group Summary

The document received a detailed early IoT directorate review.

Document Quality

At least three public implementations of the protocol are available:
1. wpa_supplicant - https://github.com/tuomaura/eap-noob
2. contiki - https://github.com/eduingles/coap-eap-noob
3. hostap - https://github.com/Vogeltak/hostap

The protocol has security proofs:
1. Proverif: 
https://github.com/tuomaura/eap-noob/tree/master/protocolmodel/proverif
2. mcrl2: https://github.com/tuomaura/eap-noob/tree/master/protocolmodel/mcrl2

Personnel

Document Shepherd - Joe Salowey

Responsible AD - Roman Danyliw

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Last Call: (Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3)) to Proposed Standard

[The IESG]

The IESG has received a request from the EAP Method Update WG (emu) to
consider the following document: - 'Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3)'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2021-09-20. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   The Extensible Authentication Protocol (EAP), defined in RFC 3748,
   provides a standard mechanism for support of multiple authentication
   methods.  This document specifies the use of EAP-Transport Layer
   Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible
   with existing implementations of EAP-TLS.  TLS 1.3 provides
   significantly improved security, privacy, and reduced latency when
   compared to earlier versions of TLS.  EAP-TLS with TLS 1.3 (EAP-TLS
   1.3) further improves security and privacy by always providing
   forward secrecy, never disclosing the peer identity, and by mandating
   use of revocation checking.  This document also provides guidance on
   authentication, authorization, and resumption for EAP-TLS in general
   (regardless of the underlying TLS version used).  This document
   updates RFC 5216.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/



No IPR declarations have been submitted directly on this I-D.





___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Document Action: 'Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')' to Informational RFC (draft-ietf-emu-rfc5448bis-10.txt)

[The IESG]

The IESG has approved the following document:
- 'Improved Extensible Authentication Protocol Method for 3GPP Mobile
   Network Authentication and Key Agreement (EAP-AKA')'
  (draft-ietf-emu-rfc5448bis-10.txt) as Informational RFC

This document is the product of the EAP Method Update Working Group.

The IESG contact persons are Benjamin Kaduk and Roman Danyliw.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/





Technical Summary

   The 3GPP Mobile Network Authentication and Key Agreement (AKA) is the
   primary authentication mechanism for devices wishing to access mobile
   networks.  RFC 4187 (EAP-AKA) made the use of this mechanism possible
   within the Extensible Authentication Protocol (EAP) framework.  RFC
   5448 (EAP-AKA') was an improved version of EAP-AKA.

   This memo replaces the specification of EAP-AKA'.  EAP-AKA' was
   defined in RFC 5448 and updated EAP-AKA RFC 4187.  As such this
   document obsoletes RFC 5448 and updates RFC 4187.

   EAP-AKA' differs from EAP-AKA by providing a key derivation function
   that binds the keys derived within the method to the name of the
   access network.  The key derivation function has been defined in the
   3rd Generation Partnership Project (3GPP).  EAP-AKA' allows its use
   in EAP in an interoperable manner.  EAP-AKA' also updates the
   algorithm used in hash functions, as it employs SHA-256 / HMAC-
   SHA-256 instead of SHA-1 / HMAC-SHA-1 as in EAP-AKA.

   This version of EAP-AKA' specification specifies the protocol
   behaviour for both 4G and 5G deployments, whereas the previous
   version only did this for 4G.

Working Group Summary

   There was consensus for the document in the working group.  

Document Quality

   This document is used by 3GPP standards including 5G standards and 
   has had review from members of that community.

Personnel

   Joe Salowey is the document shepherd.
   Roman Danyliw is the Responsible AD. 


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Last Call: (Nimble out-of-band authentication for EAP (EAP-NOOB)) to Proposed Standard

[The IESG]

The IESG has received a request from the EAP Method Update WG (emu) to
consider the following document: - 'Nimble out-of-band authentication for EAP
(EAP-NOOB)'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2021-04-13. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   The Extensible Authentication Protocol (EAP) provides support for
   multiple authentication methods.  This document defines the EAP-NOOB
   authentication method for nimble out-of-band (OOB) authentication and
   key derivation.  The EAP method is intended for bootstrapping all
   kinds of Internet-of-Things (IoT) devices that have no pre-configured
   authentication credentials.  The method makes use of a user-assisted
   one-directional OOB message between the peer device and
   authentication server to authenticate the in-band key exchange.  The
   device must have an input or output interface, such as a display,
   microphone, speaker or blinking light, which can send or receive
   dynamically generated messages of tens of bytes in length.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/



No IPR declarations have been submitted directly on this I-D.





___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Document Action: 'Handling Large Certificates and Long Certificate Chains in TLS-based EAP Methods' to Informational RFC (draft-ietf-emu-eaptlscert-08.txt)

[The IESG]

The IESG has approved the following document:
- 'Handling Large Certificates and Long Certificate Chains in TLS-based
   EAP Methods'
  (draft-ietf-emu-eaptlscert-08.txt) as Informational RFC

This document is the product of the EAP Method Update Working Group.

The IESG contact persons are Benjamin Kaduk and Roman Danyliw.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/





Technical Summary

   The Extensible Authentication Protocol (EAP), defined in RFC3748,
   provides a standard mechanism for support of multiple authentication
   methods.  EAP-Transport Layer Security (EAP-TLS) and other TLS-based
   EAP methods are widely deployed and used for network access
   authentication.  Large certificates and long certificate chains
   combined with authenticators that drop an EAP session after only 40 -
   50 round-trips is a major deployment problem.  This document looks at
   the this problem in detail and describes the potential solutions
   available.

Working Group Summary

There was good support in the working group for this document.  There we 
several substantive reviews of the document. 

Document Quality

This document has be reviewed by members of the EAP and the TLS community.  
Some of the mechanisms in the document are being implemented. 

Personnel

Joseph Salowey is the document shepherd
Roman Danyliw is the responsible AD


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Last Call: (Using EAP-TLS with TLS 1.3) to Proposed Standard

[The IESG]

The IESG has received a request from the EAP Method Update WG (emu) to
consider the following document: - 'Using EAP-TLS with TLS 1.3'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2020-10-29. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   This document specifies the use of EAP-TLS with TLS 1.3 while
   remaining backwards compatible with existing implementations of EAP-
   TLS.  TLS 1.3 provides significantly improved security, privacy, and
   reduced latency when compared to earlier versions of TLS.  EAP-TLS
   with TLS 1.3 further improves security and privacy by mandating use
   of privacy and revocation checking.  This document also provides
   guidance on authorization and resumption for EAP-TLS in general
   (regardless of the underlying TLS version used).  This document
   updates RFC 5216.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/



No IPR declarations have been submitted directly on this I-D.





___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Last Call: (Handling Large Certificates and Long Certificate Chains in TLS-based EAP Methods) to Informational RFC

[The IESG]

The IESG has received a request from the EAP Method Update WG (emu) to
consider the following document: - 'Handling Large Certificates and Long
Certificate Chains in TLS-based
   EAP Methods'
   as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2020-10-28. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   EAP-TLS and other TLS-based EAP methods are widely deployed and used
   for network access authentication.  Large certificates and long
   certificate chains combined with authenticators that drop an EAP
   session after only 40 - 50 round-trips is a major deployment problem.
   This document looks at the this problem in detail and describes the
   potential solutions available.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/



No IPR declarations have been submitted directly on this I-D.





___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Protocol Action: 'EAP Session-Id Derivation for EAP-SIM, EAP-AKA, and PEAP' to Proposed Standard (draft-ietf-emu-eap-session-id-06.txt)

[The IESG]

The IESG has approved the following document:
- 'EAP Session-Id Derivation for EAP-SIM, EAP-AKA, and PEAP'
  (draft-ietf-emu-eap-session-id-06.txt) as Proposed Standard

This document is the product of the EAP Method Update Working Group.

The IESG contact persons are Benjamin Kaduk and Roman Danyliw.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-session-id/





Technical Summary

   EAP Session-Id derivation has not been defined for EAP-SIM or EAP-AKA
   when using the fast re-authentication exchange instead of full
   authentication.  This document updates RFC 5247 to define those
   derivations for EAP-SIM and EAP-AKA.  RFC 5247 also does not define
   Session-Id derivation for PEAP.  A definition is given here which
   follows the definition for other TLS-based EAP methods.

Working Group Summary

There was nothing note worthy in the WG process which produced this document.  
The WG was looking to clarify the missing in RFC 5247.

Document Quality

Session-Ids during fast resumption for EAP-SIM and EAP-AKA has been implemented 
in at least one open source tool by Mohit Sethi. 

Personnel

The document shepherd is Mohit Sethi. 
The Area Director is Roman Danyliw.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] EAP Method Update (emu) WG Virtual Meeting: 2020-05-22 CHANGED

[IESG Secretary]

MEETING DETAILS HAVE CHANGED.  SEE LATEST DETAILS BELOW.

The EAP Method Update (emu) WG will hold
a virtual interim meeting on 2020-05-22 from 18:00 to 19:30 Europe/Helsinki 
(15:00 to 16:30 UTC).

Agenda:
Tentative initial agenda:
1. Administrivia  (5 Min)
2. TLS-based EAP types and TLS 1.3 (10 min)
3. TEAP errata and updates  (15 min)
4. EAP-TLS-PSK (15 min)
4. EAP-NOOB (15 min)
5. TEAP-BRSKI (15 min)
.



Information about remote participation:
https://ietf.webex.com/ietf/j.php?MTID=mb600f143ab22ae46181f79da1d74e8fb

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] EAP Method Update (emu) WG Virtual Meeting: 2020-05-22 CHANGED

[IESG Secretary]

MEETING DETAILS HAVE CHANGED.  SEE LATEST DETAILS BELOW.

The EAP Method Update (emu) WG will hold
a virtual interim meeting on 2020-05-22 from 18:00 to 19:30 Europe/Helsinki 
(15:00 to 16:30 UTC).

Agenda:
Tentative initial agenda:
1. Administrivia  (5 Min)
2. TLS-based EAP types and TLS 1.3 (10 min)
3. TEAP errata and updates  (15 min)
4. EAP-TLS-PSK (15 min)
4. EAP-NOOB (15 min)
5. TEAP-BRSKI (15 min)
.



Information about remote participation:
https://ietf.webex.com/ietf/j.php?MTID=mb600f143ab22ae46181f79da1d74e8fb

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Last Call: (EAP Session-Id Derivation for EAP-SIM, EAP-AKA, and PEAP) to Proposed Standard

[The IESG]

The IESG has received a request from the EAP Method Update WG (emu) to
consider the following document: - 'EAP Session-Id Derivation for EAP-SIM,
EAP-AKA, and PEAP'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2020-05-27. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   EAP Session-Id derivation has not been defined for EAP-SIM or EAP-AKA
   when using the fast re-authentication exchange instead of full
   authentication.  This document updates RFC 5247 to define those
   derivations for EAP-SIM and EAP-AKA.  RFC 5247 also does not define
   Session-Id derivation for PEAP.  A definition is given here which
   follows the definition for other TLS-based EAP methods.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-session-id/



No IPR declarations have been submitted directly on this I-D.





___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] EAP Method Update (emu) WG Virtual Meeting: 2020-05-22

[IESG Secretary]

The EAP Method Update (emu) Working Group will hold
a virtual interim meeting on 2020-05-22 from 18:00 to 19:30 Europe/Helsinki 
(15:00 to 16:30 UTC).

Agenda:
Tentative initial agenda:
1. Administrivia  (5 Min)
2. TLS-based EAP types and TLS 1.3 (10 min)
3. TEAP errata and updates  (15 min)
4. EAP-TLS-PSK (15 min)
4. EAP-NOOB (15 min)
5. TEAP-BRSKI (15 min)
.



Information about remote participation:
Remote participation with Webex. Link will be provided after approval

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] WG Action: Rechartered EAP Method Update (emu)

[The IESG]

The EAP Method Update (emu) WG in the Security Area of the IETF has been
rechartered. For additional information, please contact the Area Directors or
the WG Chairs.

EAP Method Update (emu)
---
Current status: Active WG

Chairs:
  Joseph Salowey 
  Mohit Sethi 

Assigned Area Director:
  Roman Danyliw 

Security Area Directors:
  Benjamin Kaduk 
  Roman Danyliw 

Mailing list:
  Address: emu@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/emu
  Archive: https://mailarchive.ietf.org/arch/search/?email_list=emu

Group page: https://datatracker.ietf.org/group/emu/

Charter: https://datatracker.ietf.org/doc/charter-ietf-emu/

The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access
authentication framework used, for instance, in VPN and mobile networks.
EAP itself is a simple protocol and actual authentication happens in EAP
methods. Several EAP methods have been developed at the IETF and
support for EAP exists in a broad set of devices. Previous larger EAP-related
efforts at the IETF included rewriting the base EAP protocol specification and
the development of several standards track EAP methods.

EAP methods are generally based on existing security technologies such as
Transport Layer Security (TLS) and mobile network Authentication and Key
Agreement (AKA). Our understanding of security threats is continuously
evolving. This has driven the evolution of several of these underlying
technologies. As an example, IETF has standardized a new and improved
version of TLS (v1.3) in RFC 8446. The group will therefore provide guidance
and update EAP method specifications where necessary to enable the use of
new versions of these underlying technologies.

At the same time, some new use cases for EAP have been identified. EAP is
now more broadly used in mobile network authentication. The group will
update existing EAP methods such as EAP-AKA' to stay in sync with updates
to the referenced 3GPP specifications. RFC 7258 notes that pervasive
monitoring is an attack. Forward secrecy is an important
security property for modern protocols to thwart pervasive monitoring. The
group will work on an extension to EAP-AKA' for providing PFS.

Out-of-band (OOB) refers to a separate communication channel
independent of the primary in-band channel over which the actual network
communication takes place. OOB channels are now used for authentication
in a variety of protocols and devices (draft-ietf-oauth-device-flow-13,
WhatsApp Web, etc.). Many users are accustomed to tapping NFC or
scanning QR codes. However, EAP currently does not have any standard
methods that support authentication based on OOB channels. The group
will therefore work on an EAP method where authentication is based on an
out-of-band channel between the peer and the server.

EAP authentication is based on credentials available on the peer and the
server. However, some EAP methods use credentials that are time or domain
limited (such as EAP-POTP), and there may be a need for creating long term
credentials for re-authenticating the peer in a more general context. The
group will investigate minimal mechanisms with which limited-use EAP
authentication credentials can be used for creating general-use long-term
credentials.

In summary, the working group shall produce the following documents:

* An update to enable the use of TLS 1.3 in the context of EAP-TLS
(RFC 5216). This document will update the security considerations relating to
EAP-TLS, document the implications of using new vs. old TLS versions. It will
add any recently gained new knowledge on vulnerabilities and discuss the
possible implications of pervasive surveillance.

* Several EAP methods such EAP-TTLS and EAP-FAST use an outer TLS
tunnel. Provide guidance or update the relevant specifications explaining
how those EAP methods (PEAP/TTLS/TEAP) will work with TLS 1.3. This will
also involve maintenance work based on errata found in published
specifications (such as EAP-TEAP).

* Define session identifiers for fast re-authentication for EAP-SIM,
EAP-AKA, EAP-PEAP and EAP-AKA’. The lack of this definition is a recently
discovered bug in the original RFCs.

* Update the EAP-AKA' specification (RFC 5448) to ensure that its
capability to provide a cryptographic binding to network context stays in
sync with updates to the referenced 3GPP specifications. The document will
also contain any recently gained new knowledge on vulnerabilities or the
possible implications of pervasive surveillance.

* Develop an extension to EAP-AKA' such that forward
secrecy can be provided. There may also be privacy improvements that have
become feasible with the  introduction of recent identity privacy
improvements in 3GPP networks.

* Gather experience regarding the use of large certificates and long
certificate chains in the context of TLS based EAP methods, as some
implementations and 

[Emu] WG Review: EAP Method Update (emu)

[The IESG]

The EAP Method Update (emu) WG in the Security Area of the IETF is undergoing
rechartering. The IESG has not made any determination yet. The following
draft charter was submitted, and is provided for informational purposes only.
Please send your comments to the IESG mailing list (i...@ietf.org) by
2019-11-11.

EAP Method Update (emu)
---
Current status: Active WG

Chairs:
  Joseph Salowey 
  Mohit Sethi 

Assigned Area Director:
  Roman Danyliw 

Security Area Directors:
  Benjamin Kaduk 
  Roman Danyliw 

Mailing list:
  Address: emu@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/emu
  Archive: https://mailarchive.ietf.org/arch/search/?email_list=emu

Group page: https://datatracker.ietf.org/group/emu/

Charter: https://datatracker.ietf.org/doc/charter-ietf-emu/

The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access
authentication framework used, for instance, in VPN and mobile networks.
EAP itself is a simple protocol and actual authentication happens in EAP
methods. Several EAP methods have been developed at the IETF and
support for EAP exists in a broad set of devices. Previous larger EAP-related
efforts at the IETF included rewriting the base EAP protocol specification and
the development of several standards track EAP methods.

EAP methods are generally based on existing security technologies such as
Transport Layer Security (TLS) and mobile network Authentication and Key
Agreement (AKA). Our understanding of security threats is continuously
evolving. This has driven the evolution of several of these underlying
technologies. As an example, IETF has standardized a new and improved
version of TLS (v1.3) in RFC 8446. The group will therefore provide guidance
and update EAP method specifications where necessary to enable the use of
new versions of these underlying technologies.

At the same time, some new use cases for EAP have been identified. EAP is
now more broadly used in mobile network authentication. The group will
update existing EAP methods such as EAP-AKA' to stay in sync with updates
to the referenced 3GPP specifications. RFC 7258 notes that pervasive
monitoring is an attack. Perfect Forward Secrecy (PFS) is an important
security property for modern protocols to thwart pervasive monitoring. The
group will work on an extension to EAP-AKA' for providing PFS.

Out-of-band (OOB) refers to a separate communication channel
independent of the primary in-band channel over which the actual network
communication takes place. OOB channels are now used for authentication
in a variety of protocols and devices (draft-ietf-oauth-device-flow-13,
WhatsApp Web, etc.). Many users are accustomed to tapping NFC or
scanning QR codes. However, EAP currently does not have any standard
methods that support authentication based on OOB channels. The group
will therefore work on an EAP method where authentication is based on an
out-of-band channel between the peer and the server.

EAP authentication is based on credentials available on the peer and the
server. However, some EAP methods use credentials that are time or domain
limited (such as EAP-POTP), and there may be a need for creating long term
credentials for re-authenticating the peer in a more general context. The
group will investigate minimal mechanisms with which limited-use EAP
authentication credentials can be used for creating general-use long-term
credentials.

In summary, the working group shall produce the following documents:

* An update to enable the use of TLS 1.3 in the context of EAP-TLS
(RFC 5216). This document will update the security considerations relating to
EAP-TLS, document the implications of using new vs. old TLS versions. It will
add any recently gained new knowledge on vulnerabilities and discuss the
possible implications of pervasive surveillance.

* Several EAP methods such EAP-TTLS and EAP-FAST use an outer TLS
tunnel. Provide guidance or update the relevant specifications explaining
how those EAP methods (PEAP/TTLS/TEAP) will work with TLS 1.3. This will
also involve maintenance work based on errata found in published
specifications (such as EAP-TEAP).

* Define session identifiers for fast re-authentication for EAP-SIM,
EAP-AKA, EAP-PEAP and EAP-AKA’. The lack of this definition is a recently
discovered bug in the original RFCs.

* Update the EAP-AKA' specification (RFC 5448) to ensure that its
capability to provide a cryptographic binding to network context stays in
sync with updates to the referenced 3GPP specifications. The document will
also contain any recently gained new knowledge on vulnerabilities or the
possible implications of pervasive surveillance.

* Develop an extension to EAP-AKA' such that Perfect Forward
Secrecy can be provided. There may also be privacy improvements that have
become feasible with the  introduction of recent identity privacy
improvements in 3GPP networks

[Emu] WG Action: Formed EAP Method Update (emu)

[The IESG]

The EAP Method Update (emu) WG in the Security Area of the IETF has been
reopened. For additional information, please contact the Area Directors or
the WG Chair.

EAP Method Update (emu)
---
Current status: Proposed WG

Chairs:
  Joseph Salowey 

Assigned Area Director:
  Kathleen Moriarty 

Security Area Directors:
  Kathleen Moriarty 
  Eric Rescorla 

Mailing list:
  Address: emu@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/emu
  Archive: https://mailarchive.ietf.org/arch/search/?email_list=emu

Group page: https://datatracker.ietf.org/group/emu/

Charter: https://datatracker.ietf.org/doc/charter-ietf-emu/

The Extensible Authentication Protocol (EAP) [RFC 3748] is a network
access authentication framework used, for instance, in 802.11 and VPN
networks and mobile networks. EAP itself is a simple
protocol and actual authentication happens in EAP methods.

Over 50 different EAP methods exist, including several methods
developed in the IETF, and support for EAP exists in a broad set
of different devices. Previous larger EAP-related efforts at the
IETF included rewriting the base EAP protocol documentation and
the development of several standards track EAP methods.

EAP methods are generally based on existing other security
technologies, such as TLS, SIM cards, and various algorithms.
Some of these technologies continue to evolve. The
understanding of security threats in today's Internet evolves as
well, which has driven some of the evolution in these underlying
technologies. At the same time, some new use cases for EAP have
been identified, such as broader use of EAP in mobile network
authentication.

This working group has been chartered to provide updates to some
commonly used EAP methods. Specifically, the working group shall
produce documents to:

   - Provide a guidance or update to enable the use of TLS 1.3 in the
 context of EAP TLS (RFC 5216). Update the security
 considerations relating to EAP TLS, to document the implications
 of using new vs. old TLS versions, any recently gained new
 knowledge on vulnerabilities, and the possible implications of
 pervasive surveillance.

   - Update the EAP-AKA' specification (RFC 5448) to ensure that its
 capability to provide a cryptographic binding to network context
 stays in sync with what updates may come to the referenced 3GPP
 specifications through the use of EAP in 5G.

 Also, the group should document any recently gained new
 knowledge on vulnerabilities or the possible implications of
 pervasive surveillance or other new concerns.

   - Define session identifiers for fast re-authentication for
 EAP-SIM, EAP-AKA, and EAP-AKA’. The lack of this definition
 is a recently discovered bug in the original RFCs.

   - Develop an extension to EAP-AKA' such that Perfect Forward Secrecy
 can be provided. There may also be privacy improvements that
 have become feasible with the introduction of recent identity
 privacy improvements in 3GPP networks.

   - Gather experience regarding the use of large certificate and
 certificate chain sizes in the context of EAP-TLS (all versions),
 as some implementations and access networks may limit the
 number of EAP packet exchanges that can be handled.
 Document operational recommendations or other mitigation
 strategies to avoid issues.

In all of the above, it is a requirement that none of the updates
break backwards compatibility with existing specifications or
implementations. The current EAP-TLS RFCs will not be obsoleted but
rather updated with either new information or instructions on
what is needed, for instance, to employ a new TLS version.

The working group is expected to stay in close collaboration with
the EAP deployment community, the TLS working group (for EAP-TLS
work), and the 3GPP security architecture group (for EAP-AKA'
work).

Milestones:

  Mar 2018 - Working Group Established

  Apr 2018 - WG adopts initial draft on guidance for EAP TLS with TLS 1.3

  Apr 2018 - WG adopts initial draft on EAP-AKA update, RFC5448-bis,
  including definition session identifiers for fast re-authentication for
  EAP-AKA'

  Sep 2018 - WG last call on EAP-AKA update, RFC5448-bis

  Oct 2018 - WG adopts initial draft on extension to EAP-AKA to support
  forward secrecy

  Oct 2018 - WG adopts initial draft on definition of session identifiers for
  fast re-authentication for EAP-SIM and EAP-AKA

  Nov 2018 - WG last call on guidance for EAP TLS with TLS 1.3

  Dec 2018 - WG adopts initial draft on operational recommendations for large
  certificate and chain sizes

  Jan 2019 - WG last call on definition of session identifiers for fast 
  re-authentication in EAP-SIM and EAP-AKA

  Feb 2019 - WG last call on extension to EAP-AKA to support forward secrecy

[Emu] WG Action: Conclusion of EAP Method Update (emu)

[IESG Secretary]

The EAP Method Update (emu) in the Security Area has concluded. The IESG 
contact person is Kathleen Moriarty.

The mailing list will remain active.

The EMU working group has successfully completed the milestones in
the charter. The working group is now closed, however the mailing
list will remain open. Thank you to the chairs, editors, and working
group for their diligent work on EAP Method Update. A special thank
you to the chairs, Joseph Salowey and Alan DeKok.

WG: http://datatracker.ietf.org/wg/emu/charter/

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Protocol Action: 'Tunnel EAP Method (TEAP) Version 1' to Proposed Standard (draft-ietf-emu-eap-tunnel-method-10.txt)

[The IESG]

The IESG has approved the following document:
- 'Tunnel EAP Method (TEAP) Version 1'
  (draft-ietf-emu-eap-tunnel-method-10.txt) as Proposed Standard

This document is the product of the EAP Method Update Working Group.

The IESG contact persons are Sean Turner and Stephen Farrell.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/




Technical Summary

This document defines the Tunnel Extensible Authentication Protocol
(TEAP) version 1. TEAP is a tunnel based EAP method that enables
secure communication between a peer and a server by using the
Transport Layer Security (TLS) to establish a mutually authenticated
tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used
to convey authentication related data between the EAP peer and the
EAP server.

Working Group Summary

At the start of this work there were different proposals. Through a
long process the working group settled on the current approach and
document. There is good consensus from the working group on this document.

Document Quality

This document has had review from different groups including EMU, ABFAB,
NEA and RADEXT.

Personnel

Alan DeKok is the document Shepherd.
Sean Turner is the responsible AD.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Protocol Action: 'Channel Binding Support for EAP Methods' to Proposed Standard (draft-ietf-emu-chbind-16.txt)

[The IESG]

The IESG has approved the following document:
- 'Channel Binding Support for EAP Methods'
  (draft-ietf-emu-chbind-16.txt) as Proposed Standard

This document is the product of the EAP Method Update Working Group.

The IESG contact persons are Sean Turner and Stephen Farrell.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-emu-chbind/




Technical Summary

   This document defines how to implement channel bindings for
   Extensible Authentication Protocol (EAP) methods to address
   the lying NAS as well as the lying provider problem.

Working Group Summary

   This document has had extensive review in the EMU working
   group. The document has clear applicability in ABFAB and
   Network Access use cases.

Document Quality

   Project Moonshot, an ABFAB implementation, is working on an
   implementation of this document. 

Personnel

  Joe Salowey (jsalo...@cisco.com), EMU working group co-chair, is the
  Working Group Shepherd for this document.
  Sean Turner (turn...@ieca.com) is the responsible AD.

RFC Editor Note

Two things:

1) s9.1: r/subvirt/subvert

2) Title page (xml2rfc fun on the title page):

OLD:

 T. Clancy
  Department of Electrical
Engineering and Computer Science

NEW:

 T. Clancy
   Virginia Tech



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Last Call: draft-ietf-emu-chbind-14.txt (Channel Binding Support for EAP Methods) to Proposed Standard

[The IESG]

The IESG has received a request from the EAP Method Update WG (emu) to
consider the following document:
- 'Channel Binding Support for EAP Methods'
  draft-ietf-emu-chbind-14.txt as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2012-04-12. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document defines how to implement channel bindings for
   Extensible Authentication Protocol (EAP) methods to address the lying
   NAS as well as the lying provider problem.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-emu-chbind/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-emu-chbind/ballot/


No IPR declarations have been submitted directly on this I-D.


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Last Call: draft-ietf-emu-eaptunnel-req-08.txt (Requirements for a Tunnel Based EAP Method) to Informational RFC

[The IESG]

The IESG has received a request from the EAP Method Update WG (emu) to consider 
the following document:

- 'Requirements for a Tunnel Based EAP Method'
  draft-ietf-emu-eaptunnel-req-08.txt as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final 
comments on this action. Please send substantive comments to the i...@ietf.org 
mailing lists by 2010-11-10. Exceptionally, comments may be sent to 
i...@ietf.org instead. In either case, please retain the beginning of the 
Subject line to allow automated sorting.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-emu-eaptunnel-req/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-emu-eaptunnel-req/


No IPR declarations were found that appear related to this I-D.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Potential Notes in EAP-FAST Documents

[The IESG]

Dear EMU WG:

These two documents are in the RFC Editor queue:

   draft-cam-winget-eap-fast-provisioning-10.txt
   draft-zhou-emu-fast-gtc-05.txt

The IESG has received a very late comment about these documents, and
we seek your input on the proposed resolution.

The late comment raises a potential interoperability concern with
existing implementations of EAP-MSCHAPv2 and EAP-GTC.
 
The draft-cam-winget-eap-fast-provisioning-10.txt document specifies
a very specific way to generate the challenges used in EAP-MSCHAPv2
that provides binding between the EAP-FAST tunnel and the EAP-MSCHAPv2
exchanges.

The draft-zhou-emu-fast-gtc-05.txt describes EAP-FAST-GTC, which is
uses EAP Type 6, originally allocated to EAP-GTC [RFC3748]. EAP-FAST-GTC
employs a subset of the EAP-GTC formatting.

The IESG recognizes the difficulties caused by re-use of an EAP Type.
Further, the IESG recognizes the concern about implementations that
might not easily adapt to additional requirements.  However, the IESG
also recognizes the significant value in documenting EAP methods that
are implemented and deployed in the Internet today.

The IESG believes that the right thing to do in this situation is to
proceed with the publication of these documents.  However, the IESG also
sees value in warning future EAP method designers about this experience
so that this pain might be avoided in the future.

The IESG is considering the additional informative paragraph in the IANA
considerations section of both documents that says:

IESG Note: EAP-FAST has been implemented by many vendors and it is
used in the Internet.  Publication of this is intended to promote
interoperability, even though the use of the EAP-MSCHAPv2 and
EAP-FAST-GTC EAP methods might be difficult in some software
environments.  If EAP-FAST were to be designed today, these
difficulties could be avoided by the assignment of new EAP Type
codes.

Please provide comments on the proposed way forward.

On behalf of the IESG,
  Russ

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Protocol Action: 'EAP Generalized Pre-Shared Key (EAP-GPSK) Method' to Proposed Standard

[The IESG]

The IESG has approved the following document:

- 'EAP Generalized Pre-Shared Key (EAP-GPSK) Method '
   draft-ietf-emu-eap-gpsk-17.txt as a Proposed Standard

This document is the product of the EAP Method Update Working Group. 

The IESG contact persons are Pasi Eronen and Tim Polk.

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

Technical Summary

   This document defines an Extensible Authentication Protocol method
   called EAP Generalized Pre-Shared Key (EAP-GPSK). This method is a
   lightweight shared-key authentication protocol supporting mutual
   authentication and key derivation. The method should be able to
   support any future EAP channel binding requirements.

Working Group Summary

   The base document for EAP-GPSK was originally created by a design
   team. There was working group consensus to accept the document to
   meet the Pre-Shared-Key EAP method on the working group charter.

Document Quality

   There is an existing implementation of the protocol. NIST was
   consulted and participated in the review of the document resulting
   in some modifications to the key derivation function. The document
   has been reviewed by external researchers and their feedback has
   been incorporated. EAP experts within the EMU working group have
   reviewed the document. This document meets requirements set forth
   in RFC 3748, RFC 4017, and RFC 5247.

Personnel

   Joe Salowey is the document shepherd. The responsible
   Area Director is Pasi Eronen.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] WG Action: RECHARTER: EAP Method Update (emu)

[IESG Secretary]

The EAP Method Update (emu) working group in the Security Area of the IETF
has been rechartered.  For additional information, please contact the Area
Directors or the working group Chairs.

EAP Method Update (emu)


Last Modified: 2008-05-22

Current Status: Active Working Group

Chair(s):
Joseph Salowey ([EMAIL PROTECTED])
Alan DeKok ([EMAIL PROTECTED])

Security Area Director(s):
Tim Polk ([EMAIL PROTECTED])
Pasi Eronen ([EMAIL PROTECTED])

Security Area Advisor:
Pasi Eronen ([EMAIL PROTECTED])

Mailing Lists:
General Discussion: emu@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/emu
Archive: http://www.ietf.org/mail-archive/web/emu/current/index.html

Description of Working Group:

The Extensible Authentication Protocol (EAP) [RFC 3748] is a network
access authentication framework used in the PPP, 802.11, 802.16, VPN,
PANA, and in some functions in 3G networks. EAP itself is a simple
protocol and actual authentication happens in EAP methods.

Over 40 different EAP methods exist. Most of these methods are
proprietary methods, but some are documented in informational RFCs. In
the past the lack of documented, open specifications has been a
deployment and interoperability problem. There are currently only two
EAP methods in the standards track that implement features such as key
derivation that are required for many modern applications.
Authentication types and credentials continue to evolve as do
requirements for EAP methods.

This group is chartered to work on the following types of mechanisms
to meet requirements relevant to EAP methods in RFC 3748, RFC 4017,
RFC 4962 and EAP Keying:

- A mechanism based on strong shared secrets. This mechanism should
strive to be simple and compact for implementation in resource
constrained environments.

- A document that defines EAP channel bindings and provides guidance
for establishing EAP channel bindings within EAP methods.

- Enable TLS-based EAP methods to support channel bindings. This item
will not generate a new method; rather, it will focus on adding
support for EAP channel bindings to the tunneled method (described
below), and if possible, other TLS-based EAP methods. Potential
mechanisms for adding channel binding support will be investigated,
including tunneling of channel binding parameters, or a TLS extension,
or other standard TLS mechanism

- A mechanism to support extensible communication within a TLS
protected tunnel. This mechanism will support meeting the requirements
of an enhanced TLS mechanism, a password based authentication
mechanism, and additional inner authentication mechanisms. It will
also support channel bindings (as described above) in order to meet
RFC 4962 requirements.

- A mechanism that makes use of existing password databases such as AAA
databases. This item will be based on the above tunnel method.

Goals and Milestones:

Jun 2008 Submit Tunnel and Password Method requirements first Draft
Sep 2008 Submit EAP Channel Bindings First Draft
Sep 2008 Submit Tunnel Method first draft
Oct 2008 Submit TLS based method channel binding first draft
Oct 2008 Submit Password Method first draft
Jan 2009 Send EAP Channel Bindings to IESG
Mar 2009 Send Tunnel Method to IESG
Apr 2009 Send TLS based method channel binding to IESG
Apr 2009 Send Password based method to IESG
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Protocol Action: 'The EAP TLS Authentication Protocol' to Proposed Standard

[The IESG]

The IESG has approved the following document:

- 'The EAP TLS Authentication Protocol '
   draft-simon-emu-rfc2716bis-13.txt as a Proposed Standard

This document is the product of the EAP Method Update Working Group. 

The IESG contact persons are Sam Hartman and Tim Polk.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-13.txt

Technical Summary
 
   The Extensible Authentication Protocol (EAP), defined in RFC 3748,
   provides support for multiple authentication methods. Transport Level
   Security (TLS) provides for mutual authentication, integrity-protected
   ciphersuite negotiation and key exchange between two endpoints. This
   document defines EAP-TLS, which includes support for certificate-based
   mutual authentication and key derivation. This document obsoletes RFC
   2716 to bring EAP-TLS into the standards track.
 
Working Group Summary
 
   The document represents rough consensus of the working group.
 
Protocol Quality
 
This document has been reviewed for the IESG by Sam Hartman.   There are
many interoperable implementation of EAP-TLS deployed today.
   This document has been reviewed by people involved in the EAP, TLS and
   PKIX working groups.


Note to RFC Editor
 
Please replace Section 2.4 with the following text:

2.4.  Ciphersuite and Compression Negotiation

  EAP-TLS implementations MUST support TLS v1.0.

  EAP-TLS implementations need not necessarily support all TLS
  ciphersuites listed in [RFC4346].  Not all TLS ciphersuites are
  supported by available TLS tool kits and licenses may be required in
  some cases.

  To ensure interoperability, EAP-TLS peers and servers MUST support
  the TLS [RFC4346] mandatory-to-implement ciphersuite:

  TLS_RSA_WITH_3DES_EDE_CBC_SHA

  EAP-TLS peers and servers SHOULD also support and be able
  to negotiate the following TLS ciphersuites:

TLS_RSA_WITH_RC4_128_SHA [RFC4346]
TLS_RSA_WITH_AES_128_CBC_SHA [RFC3268]

  In addition, EAP-TLS servers SHOULD support and be able to negotiate
  the following TLS ciphersuite:

  TLS_RSA_WITH_RC4_128_MD5 [RFC4346]

  Since TLS supports ciphersuite negotiation, peers completing the TLS
  negotiation will also have selected a ciphersuite, which includes
  encryption and hashing methods.  Since the ciphersuite negotiated
  within EAP-TLS applies only to the EAP conversation, TLS ciphersuite
  negotiation MUST NOT be used to negotiate the ciphersuites used to
  secure data.

  TLS also supports compression as well as ciphersuite negotiation.
  However, during the EAP-TLS conversation the EAP peer and server MUST
  NOT request or negotiate compression.



___
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu