draft-ietf-emu-eap-tls13-10.txt   draft-ietf-emu-eap-tls13-11.txt 
Network Working Group J. Mattsson Network Working Group J. Mattsson
Internet-Draft M. Sethi Internet-Draft M. Sethi
Updates: 5216 (if approved) Ericsson Updates: 5216 (if approved) Ericsson
Intended status: Standards Track June 7, 2020 Intended status: Standards Track October 14, 2020
Expires: December 9, 2020 Expires: April 17, 2021
Using EAP-TLS with TLS 1.3 Using EAP-TLS with TLS 1.3
draft-ietf-emu-eap-tls13-10 draft-ietf-emu-eap-tls13-11
Abstract Abstract
This document specifies the use of EAP-TLS with TLS 1.3 while This document specifies the use of EAP-TLS with TLS 1.3 while
remaining backwards compatible with existing implementations of EAP- remaining backwards compatible with existing implementations of EAP-
TLS. TLS 1.3 provides significantly improved security, privacy, and TLS. TLS 1.3 provides significantly improved security, privacy, and
reduced latency when compared to earlier versions of TLS. EAP-TLS reduced latency when compared to earlier versions of TLS. EAP-TLS
with TLS 1.3 further improves security and privacy by mandating use with TLS 1.3 further improves security and privacy by mandating use
of privacy and revocation checking. This document also provides of privacy and revocation checking. This document also provides
guidance on authorization and resumption for EAP-TLS in general guidance on authorization and resumption for EAP-TLS in general
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 9, 2020. This Internet-Draft will expire on April 17, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 41 skipping to change at page 2, line 41
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 19 5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 19
5.2. Peer and Server Identities . . . . . . . . . . . . . . . 20 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 20
5.3. Certificate Validation . . . . . . . . . . . . . . . . . 20 5.3. Certificate Validation . . . . . . . . . . . . . . . . . 20
5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 20 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 20
5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 20 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 20
5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 21 5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 21
5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 21 5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 21
5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 23 5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 23
5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 24 5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 24
5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 24 5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 25
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1. Normative References . . . . . . . . . . . . . . . . . . 25 6.1. Normative References . . . . . . . . . . . . . . . . . . 25
6.2. Informative references . . . . . . . . . . . . . . . . . 26 6.2. Informative references . . . . . . . . . . . . . . . . . 26
Appendix A. Updated references . . . . . . . . . . . . . . . . . 29 Appendix A. Updated references . . . . . . . . . . . . . . . . . 30
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
provides a standard mechanism for support of multiple authentication provides a standard mechanism for support of multiple authentication
methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216] specifies methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216] specifies
an EAP authentication method with certificate-based mutual an EAP authentication method with certificate-based mutual
authentication utilizing the TLS handshake protocol for cryptographic authentication utilizing the TLS handshake protocol for cryptographic
algorithms and protocol version negotiation, mutual authentication, algorithms and protocol version negotiation, mutual authentication,
skipping to change at page 17, line 45 skipping to change at page 17, line 45
after the main handshake. One such Post-Handshake message is after the main handshake. One such Post-Handshake message is
NewSessionTicket. The NewSessionTicket can be used for resumption. NewSessionTicket. The NewSessionTicket can be used for resumption.
After sending TLS Finished, the EAP server may send any number of After sending TLS Finished, the EAP server may send any number of
Post-Handshake messages in separate EAP-Requests. To decrease the Post-Handshake messages in separate EAP-Requests. To decrease the
uncertainty for the EAP peer, the following procedure MUST be uncertainty for the EAP peer, the following procedure MUST be
followed: followed:
When an EAP server has sent its last handshake message (Finished or a When an EAP server has sent its last handshake message (Finished or a
Post-Handshake), it commits to not sending any more handshake Post-Handshake), it commits to not sending any more handshake
messages by sending a Commitment Message. The Commitment Message is messages by sending a Commitment Message. The Commitment Message is
a TLS record with application data 0x00 (i.e. a TLS record with an encrypted TLS record with application data 0x00 (i.e. a TLS record
TLSPlaintext.type = application_data, TLSPlaintext.length = 1, and with TLSPlaintext.type = application_data, TLSPlaintext.length = 1,
TLSPlaintext.fragment = 0x00). Note that the length of the plaintext and TLSPlaintext.fragment = 0x00). Note that the length of the
is greater than the corresponding TLSPlaintext.length due to the plaintext is greater than the corresponding TLSPlaintext.length due
inclusion of TLSInnerPlaintext.type and any padding supplied by the to the inclusion of TLSInnerPlaintext.type and any padding supplied
sender. EAP server implementations MUST set TLSPlaintext.fragment to by the sender. EAP server implementations MUST set
0x00, but EAP peer implementations MUST accept any application data TLSPlaintext.fragment to 0x00, but EAP peer implementations MUST
as a Commitment Message from the EAP server to not send any more accept any application data as a Commitment Message from the EAP
handshake messages. The Commitment Message may be sent in the same server to not send any more handshake messages. The Commitment
EAP-Request as the last handshake record or in a separate EAP- Message may be sent in the same EAP-Request as the last handshake
Request. Sending the Commitment Message in a separate EAP-Request record or in a separate EAP-Request. Sending the Commitment Message
adds an additional round-trip, but may be necessary in TLS in a separate EAP-Request adds an additional round-trip, but may be
implementations that only implement a subset of TLS 1.3. In the case necessary in TLS implementations that only implement a subset of TLS
where the server sends the Commitment Message in a separate EAP- 1.3. In the case where the server sends the Commitment Message in a
Request, the conversation will appear as shown in Figure 9. After separate EAP-Request, the conversation will appear as shown in
sending the Commitment Message, the EAP server may only send an EAP- Figure 9. After sending the Commitment Message, the EAP server may
Success, an EAP-Failure, or an EAP-Request with a TLS Alert Message. only send an EAP-Success, an EAP-Failure, or an EAP-Request with a
TLS Alert Message.
EAP Peer EAP Server EAP Peer EAP Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
skipping to change at page 21, line 51 skipping to change at page 21, line 51
There are a number of security issues related to resumption that are There are a number of security issues related to resumption that are
not described in [RFC5216]. The problems, guidelines, and not described in [RFC5216]. The problems, guidelines, and
requirements in this section therefore applies to all version of TLS. requirements in this section therefore applies to all version of TLS.
When resumption occurs, it is based on cached information at the TLS When resumption occurs, it is based on cached information at the TLS
layer. To perform resumption in a secure way, the EAP-TLS peer and layer. To perform resumption in a secure way, the EAP-TLS peer and
EAP-TLS server need to be able to securely retrieve authorization EAP-TLS server need to be able to securely retrieve authorization
information such as certificate chains from the initial full information such as certificate chains from the initial full
handshake. We use the term "cached data" to describe such handshake. We use the term "cached data" to describe such
information. Authorization during resumption MUST be based on such information. Authorization during resumption MUST be based on such
cached data. The EAP peer and sever MAY perform fresh revocation cached data. The EAP peer and server MAY perform fresh revocation
checks on the cached certificate data. Any security policies for checks on the cached certificate data. Any security policies for
authorization MUST be followed also for resumption. The certificates authorization MUST be followed also for resumption. The certificates
may have been revoked since the initial full handshake and the may have been revoked since the initial full handshake and the
authorizations of the other party may have been reduced. If the authorizations of the other party may have been reduced. If the
cached revocation information is not sufficiently current, the EAP cached revocation is not sufficiently current, the EAP Peer or EAP
Peer or EAP Server MAY force a full TLS handshake. Server MAY force a full TLS handshake.
There are two ways to retrieve the cached information from the There are two ways to retrieve the cached data from the original full
original full handshake. The first method is that the TLS server and handshake. The first method is that the TLS server and client cache
client cache the information locally. The cached information is the information locally. The cached information is identified by an
identified by an identifier. For TLS versions before 1.3, the identifier. For TLS versions before 1.3, the identifier can be the
identifier can be the session ID, for TLS 1.3, the identifier is the session ID, for TLS 1.3, the identifier is the PSK identity. The
PSK identity. The second method for retrieving cached information is second method for retrieving cached information is via [RFC5077] or
via [RFC5077] or [RFC8446], where the TLS server encapsulates the [RFC8446], where the TLS server avoids storing information locally
information into a ticket and sends it to the client. The client can and instead encapsulates the information into a ticket or PSK which
subsequently do resumption using the obtained ticket. Note that the is sent to the client for storage. This ticket or PSK is encrypted
client still needs to cache the information locally. The following using a key that only the server knows. Note that the client still
requirements apply to both methods. needs to cache the original handshake information locally and will
use the session ID or PSK identity to lookup this information during
resumption. However, the server is able to decrypt the ticket or PSK
to obtain the original handshake information.
If the EAP server or EAP client do not apply any authorization If the EAP server or EAP client do not apply any authorization
policies, they MAY allow resumption where no cached data is policies, they MAY allow resumption where no cached data is
available. In all other cases, they MUST cache data during the available. In all other cases, they MUST cache data during the
initial full authentication to enable resumption. The cached data initial full authentication to enable resumption. The cached data
MUST be sufficient to make authorization decisions during resumption. MUST be sufficient to make authorization decisions during resumption.
If cached data cannot be retrieved in a secure way, resumption MUST If cached data cannot be retrieved in a secure way, resumption MUST
NOT be done. NOT be done.
The above requirements also apply if the EAP server expects some The above requirements also apply if the EAP server expects some
system to perform accounting for the session. Since accounting must system to perform accounting for the session. Since accounting must
be tied to an authenticated identity, and resumption does not supply be tied to an authenticated identity, and resumption does not supply
such an identity, accounting is impossible without access to cached such an identity, accounting is impossible without access to cached
data. data. Therefore systems which expect to perform accounting for the
session SHOULD cache an identifier which can be used in subsequent
accounting.
As suggested in [RFC8446], peers MUST NOT store resumption PSKs or
tickets (and associated cached data) for longer than 7 days,
regardless of the PSK or ticket lifetime. The peer MAY delete them
earlier based on local policy. The cached data MAY also be removed
on the server or peer if any certificate in the certificate chain has
been revoked or has expired. In all such cases, resumption results
in a full TLS handshake instead.
Information from the EAP-TLS exchange (e.g. the identity provided in Information from the EAP-TLS exchange (e.g. the identity provided in
EAP-Response/Identity) as well as non-EAP information (e.g. IP EAP-Response/Identity) as well as non-EAP information (e.g. IP
addresses) may change between the initial full handshake and addresses) may change between the initial full handshake and
resumption. This change creates a "Time-of-check time-of-use" resumption. This change creates a "time-of-check time-of-use"
(TOCTOU) security vulnerability. A malicious or compromised user (TOCTOU) security vulnerability. A malicious or compromised user
could supply one set of data during the initial authentication, and a could supply one set of data during the initial authentication, and a
different set of data during resumption, potentially leading to them different set of data during resumption, potentially allowing them to
obtaining access that they should not have. obtain access that they should not have.
If any authorization, accounting, or policy decisions were made with If any authorization, accounting, or policy decisions were made with
information that have changed between the initial full handshake and information that have changed between the initial full handshake and
resumption, and if change may lead to a different decision, such resumption, and if change may lead to a different decision, such
decisions MUST be reevaluated. It is RECOMMENDED that authorization, decisions MUST be reevaluated. It is RECOMMENDED that authorization,
accounting, and policy decisions are reevaluated based on the accounting, and policy decisions are reevaluated based on the
information given in the resumption. EAP servers MAY reject information given in the resumption. EAP servers MAY reject
resumption where the information supplied during resumption does not resumption where the information supplied during resumption does not
match the information supplied during the original authentication. match the information supplied during the original authentication.
Where a good decision is unclear, EAP servers SHOULD reject the Where a good decision is unclear, EAP servers SHOULD reject the
resumption. resumption.
Section 4.2.11, 8.1, and 8.2 of [RFC8446] provides security Section 4.2.11, 8.1, and 8.2 of [RFC8446] provides security
consideration for resumption. considerations for resumption.
5.8. Privacy Considerations 5.8. Privacy Considerations
This is a new section when compared to [RFC5216]. This is a new section when compared to [RFC5216].
TLS 1.3 offers much better privacy than earlier versions of TLS as TLS 1.3 offers much better privacy than earlier versions of TLS as
discussed in Section 2.1.8. In this section, we only discuss the discussed in Section 2.1.8. In this section, we only discuss the
privacy properties of EAP-TLS with TLS 1.3. For privacy properties privacy properties of EAP-TLS with TLS 1.3. For privacy properties
of TLS 1.3 itself, see [RFC8446]. of TLS 1.3 itself, see [RFC8446].
EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in
EAP packets. Additionally, the EAP peer sends an identity in the EAP packets. Additionally, the EAP peer sends an identity in the
first EAP-Response. The other fields in the EAP-TLS Request and the first EAP-Response. The other fields in the EAP-TLS Request and the
EAP-TLS Response packets do not contain any cleartext privacy EAP-TLS Response packets do not contain any cleartext privacy
sensitive information. sensitive information.
Tracking of users by eavesdropping on identity responses or Tracking of users by eavesdropping on identity responses or
certificates is a well-known problem in many EAP methods. When EAP- certificates is a well-known problem in many EAP methods. When EAP-
TLS is used with TLS 1.3, all certificates are encrypted, and the TLS is used with TLS 1.3, all certificates are encrypted, and the
username part of the identity response is always confidentiality username part of the identity response is always confidentiality
protected (e.g. using Anonymous NAIs). However, as with other EAP protected (e.g. using anonymous NAIs). However, as with other EAP
methods, even when privacy-friendly identifiers or EAP tunneling is methods, even when privacy-friendly identifiers or EAP tunneling is
used, the domain name (i.e. the realm) in the NAI is still typically used, the domain name (i.e. the realm) in the NAI is still typically
visible. How much privacy sensitive information the domain name visible. How much privacy sensitive information the domain name
leaks is highly dependent on how many other users are using the same leaks is highly dependent on how many other users are using the same
domain name in the particular access network. If all EAP peers have domain name in the particular access network. If all EAP peers have
the same domain, no additional information is leaked. If a domain the same domain, no additional information is leaked. If a domain
name is used by a small subset of the EAP peers, it may aid an name is used by a small subset of the EAP peers, it may aid an
attacker in tracking or identifying the user. attacker in tracking or identifying the user.
Without padding, information about the size of the client certificate Without padding, information about the size of the client certificate
is leaked from the size of the EAP-TLS packets. The EAP-TLS packets is leaked from the size of the EAP-TLS packets. The EAP-TLS packets
sizes may therefore leak information that can be used to track or sizes may therefore leak information that can be used to track or
identify the user. If all client certificates have the same length, identify the user. If all client certificates have the same length,
no information is leaked. EAP peers SHOULD use record padding, see no information is leaked. EAP peers SHOULD use record padding, see
Section 5.4 of [RFC8446] to reduce information leakage of certificate Section 5.4 of [RFC8446] to reduce information leakage of certificate
sizes. sizes.
If Anonymous NAIs are not used, the privacy-friendly identifiers need If anonymous NAIs are not used, the privacy-friendly identifiers need
to be generated with care. The identities MUST be generated in a to be generated with care. The identities MUST be generated in a
cryptographically secure way so that that it is computationally cryptographically secure way so that that it is computationally
infeasible for an attacker to differentiate two identities belonging infeasible for an attacker to differentiate two identities belonging
to the same user from two identities belonging to different users in to the same user from two identities belonging to different users in
the same realm. This can be achieved, for instance, by using random the same realm. This can be achieved, for instance, by using random
or pseudo-random usernames such as random byte strings or ciphertexts or pseudo-random usernames such as random byte strings or ciphertexts
and only using the pseudo-random usernames a single time. Note that and only using the pseudo-random usernames a single time. Note that
the privacy-friendly usernames also MUST NOT include substrings that the privacy-friendly usernames also MUST NOT include substrings that
can be used to relate the identity to a specific user. Similarly, can be used to relate the identity to a specific user. Similarly,
privacy-friendly username SHOULD NOT be formed by a fixed mapping privacy-friendly username SHOULD NOT be formed by a fixed mapping
skipping to change at page 26, line 32 skipping to change at page 26, line 47
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
6.2. Informative references 6.2. Informative references
[I-D.ietf-emu-eaptlscert] [I-D.ietf-emu-eaptlscert]
Sethi, M., Mattsson, J., and S. Turner, "Handling Large Sethi, M., Mattsson, J., and S. Turner, "Handling Large
Certificates and Long Certificate Chains in TLS-based EAP Certificates and Long Certificate Chains in TLS-based EAP
Methods", draft-ietf-emu-eaptlscert-03 (work in progress), Methods", draft-ietf-emu-eaptlscert-05 (work in progress),
May 2020. June 2020.
[I-D.ietf-tls-certificate-compression] [I-D.ietf-tls-certificate-compression]
Ghedini, A. and V. Vasiliev, "TLS Certificate Ghedini, A. and V. Vasiliev, "TLS Certificate
Compression", draft-ietf-tls-certificate-compression-10 Compression", draft-ietf-tls-certificate-compression-10
(work in progress), January 2020. (work in progress), January 2020.
[I-D.ietf-tls-oldversions-deprecate] [I-D.ietf-tls-oldversions-deprecate]
Moriarty, K. and S. Farrell, "Deprecating TLSv1.0 and Moriarty, K. and S. Farrell, "Deprecating TLSv1.0 and
TLSv1.1", draft-ietf-tls-oldversions-deprecate-06 (work in TLSv1.1", draft-ietf-tls-oldversions-deprecate-07 (work in
progress), January 2020. progress), October 2020.
[IEEE-802.11] [IEEE-802.11]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standard for Information technology--Telecommunications Standard for Information technology--Telecommunications
and information exchange between systems Local and and information exchange between systems Local and
metropolitan area networks--Specific requirements - Part metropolitan area networks--Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Std 802.11-2016 Layer (PHY) Specifications", IEEE Std 802.11-2016
(Revision of IEEE Std 802.11-2012) , December 2016. (Revision of IEEE Std 802.11-2012) , December 2016.
skipping to change at page 29, line 29 skipping to change at page 29, line 50
February 2015, <https://www.rfc-editor.org/info/rfc7457>. February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[TS.33.501] [TS.33.501]
3GPP, "Security architecture and procedures for 5G 3GPP, "Security architecture and procedures for 5G
System", 3GPP TS 33.501 16.1.0, December 2019. System", 3GPP TS 33.501 16.3.0, July 2020.
Appendix A. Updated references Appendix A. Updated references
All the following references in [RFC5216] are updated as specified All the following references in [RFC5216] are updated as specified
below when EAP-TLS is used with TLS 1.3 or higher. below when EAP-TLS is used with TLS 1.3 or higher.
All references to [RFC2560] are updated with [RFC6960]. All references to [RFC2560] are updated with [RFC6960].
All references to [RFC3280] are updated with [RFC5280]. All references to [RFC3280] are updated with [RFC5280].
All references to [RFC4282] are updated with [RFC7542]. All references to [RFC4282] are updated with [RFC7542].
Acknowledgments Acknowledgments
The authors want to thank Bernard Aboba, Jari Arkko, Alan DeKok, Ari The authors want to thank Bernard Aboba, Jari Arkko, Alan DeKok, Ari
Keraenen, Jouni Malinen, Oleg Pekar, Eric Rescorla, Jim Schaad, and Keraenen, Jouni Malinen, Oleg Pekar, Eric Rescorla, Jim Schaad, Terry
Vesa Torvinen for comments and suggestions on the draft. Burton, and Vesa Torvinen for comments and suggestions on the draft.
Contributors Contributors
Alan DeKok, FreeRADIUS Alan DeKok, FreeRADIUS
Authors' Addresses Authors' Addresses
John Preuss Mattsson John Preuss Mattsson
Ericsson Ericsson
Stockholm 164 40 Stockholm 164 40
 End of changes. 20 change blocks. 
54 lines changed or deleted 67 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/