Network Working Group J. Mattsson
Internet-Draft M. Sethi
Intended status: Standards Track Ericsson
Expires: September 10, 2020 T. Aura
Aalto University
O. Friel
Cisco
March 9, 2020

EAP-TLS with PSK Authentication (EAP-TLS-PSK)
draft-mattsson-emu-eap-tls-psk-00

Abstract

While TLS 1.3 supports authentication with Pre-Shared Key (PSK), EAP-TLS with TLS 1.3 explicitly forbids PSK authentication except when used for resumption. This document specifies a separate EAP method (EAP-TLS-PSK) for use cases that require authentication based on external PSKs.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 10, 2020.

Copyright Notice

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

The Extensible Authentication Protocol (EAP), defined in [RFC3748], provides a standard mechanism for support of multiple authentication methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216][I-D.ietf-emu-eap-tls13] defines an EAP authentication method with certificate-based mutual authentication and key derivation utilizing the TLS handshake protocol for cryptographic algorithms and protocol version negotiation, mutual authentication, and establishment of shared secret keying material.

While majority of TLS deployments use certificate-based authentication, earlier version of TLS have supported Pre-Shared Keys (PSK) authention as an optional feature. TLS 1.3 [RFC8446] incorporporats PSK authentication into the main specification as a main authentication method.

TLS version 1.3 [RFC8446] also uses PSKs for resuming previous TLS sessions. The specification distinguishes resumption PSKs from external PSKs that have been provisioned out of band. It also refers to external PSKs as out-of-band PSKs.

EAP-TLS [RFC5216] does not discuss the use of PSKs and EAP-TLS with TLS 1.3 [I-D.ietf-emu-eap-tls13] explicitly forbids the use of external PSKs. Nonetheless, there are examples of EAP-TLS deployments that rely on a PSK for authentication. For example, the Zigbee IP specification discusses the use of EAP-TLS with PSKs.

Although EAP already has an authentication method that supports PSKs (EAP-PSK [RFC4764]), it does not provide properties of forward secrecy or identity protection. Similary, EAP also has EAP-Pwd [RFC5931] for authentication based on user chosen passwords. It however relies on a Password Authenticated Key Exchange (PAKE). There are side-channel vulnerabilities in EAP-Pwd which are now being addressed in [I-D.harkins-eap-pwd-prime]. Implementing all the mitigations against side-channel attacks may not be possible in all environments.

This document therefore specifies EAP-TLS-PSK to allow external PSKs for mutual authentication of the peer and server.

1.1. Requirements and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED","MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Readers are expected to be familiar with the terms and concepts used in EAP-TLS [RFC5216][I-D.ietf-emu-eap-tls13] and TLS 1.3 [RFC8446].

2. Protocol Overview

2.1. Overview of the EAP-TLS-PSK Conversation

This document only lists additional and different requirements, restrictions, and processing compared to [RFC8446] and [I-D.ietf-emu-eap-tls13].

Compared to EAP-TLS with certificate authentication, EAP-TLS-PSK uses a new Type-Code (TBD).

What should the NAI be (e.g. can it be based on PSK id)? Does the PSK id need to have any specific properties?

2.1.1. Mutual Authentication

The EAP server and EAP peer MUST authenticate with an external PSK. In addition to the PSK, they can also authenticate with a certificate as specified in [I-D.ietf-tls-tls13-cert-with-extern-psk].

2.1.2. Termination

2.1.3. Hello Retry Request

2.1.4. Ticket Establishment

2.1.5. Resumption

2.1.6. Privacy

Any additional privacy considerations based on PSK ID?

2.1.7. Fragmentation

2.2. Identity Verification

NAI, PSK Identity, Server Identity

2.3. Key Hierarchy

The key derivation is performed as defined Section 2.3 of [I-D.ietf-emu-eap-tls13] with the only difference being the new Type-Code.

2.4. Parameter Negotiation and Compliance Requirements

2.5. EAP State Machines

3. IANA considerations

This document registers the following item in the "Method Types" registry under the "Extensible Authentication Protocol (EAP) Registry" heading. The 'Reference' field points to this document.

+-----------+------------------------+
| Value     | Description            |
+-----------+------------------------+
| TBD       | EAP-TLS-PSK            |
+-----------+------------------------+

Figure 1: IANA Method Types

4. Security Considerations

4.1. Security Claims

4.2. Peer and Server Identities

4.3. Authorization

4.4. Resumption

4.5. Privacy Considerations

4.6. Pervasive Monitoring

5. References

5.1. Normative References

[I-D.ietf-emu-eap-tls13] Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3", Internet-Draft draft-ietf-emu-eap-tls13-09, March 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004.
[RFC5216] Simon, D., Aboba, B. and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, March 2008.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018.

5.2. Informative references

[I-D.harkins-eap-pwd-prime] Harkins, D., "Improved Extensible Authentication Protocol Using Only a Password", Internet-Draft draft-harkins-eap-pwd-prime-00, July 2019.
[I-D.ietf-tls-tls13-cert-with-extern-psk] Housley, R., "TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key", Internet-Draft draft-ietf-tls-tls13-cert-with-extern-psk-07, December 2019.
[RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method", RFC 4764, DOI 10.17487/RFC4764, January 2007.
[RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication Protocol (EAP) Authentication Using Only a Password", RFC 5931, DOI 10.17487/RFC5931, August 2010.

Acknowledgments

The authors want to thank Elliot Lear, Alan Dekok, and Joe Salowey for their feedback on this document.

Authors' Addresses

John Preuß Mattsson Ericsson Stockholm, 164 40 Sweden EMail: john.mattsson@ericsson.com
Mohit Sethi Ericsson Jorvas, 02420 Finland EMail: mohit@piuha.net
Tuomas Aura Aalto University Aalto, 00076 Finland EMail: tuomas.aura@aalto.fi
Owen Friel Cisco EMail: ofriel@cisco.com