Draft: draft-ietf-emu-eap-tls13

Commentary: This commit addresses by adding to section 5.6 " An example of limiting network access would be to invoke a vendor 's walled garden or quarantine network functionality . " 
 draft - ietf - emu - eap - tls13 uses " Type - Code " draft - ietf - emu - tls - eap - types uses “ Type ID ” “ Type code " “ Type - Code ” RFC 3748 uses " Type " " Type field " " EAP Type Values " " Method Type values " " Type values " IANA uses " Method Types " " Value " Not a big thing , but it might be a bit confusing to a new reader of the EAP documents . This is purely editorial and can be fixed during AUTH48 . Sending to publishing should not wait on this issue . 
 From  's review of section 5 " [ 4 ] Cryptographic Negotiation : The TLS layer handles the negotiation of cryptographic parameters . When EAP - TLS is used with TLS 1.3 , EAP - TLS inherits the cryptographic negotiation of AEAD algorithm , HKDF hash algorithm , key exchange groups , and signature algorithm , see Section 4.1.1 of [ RFC8446 ] . " " The EAP - TLS server or EAP client MUST cache data during the initial full handshake sufficient to allow authorization decisions to be made during resumption . If cached data can not be retrieved in a secure way , resumption MUST NOT be done . " 
 Maybe just delete " While certificates may have long validity periods , " 
 I have commits to addressing all these comments based on the suggestions above . 
 I think PR addresses this issue . 
 Fixed in -17 
 Section 2.2 specifies some behavior that is widely implemented , but not covered in RFC 5216 . This should be indicated : " While this requirement to verify domain names is new , and was not mentioned in [ RFC5216 ] , it has been widely implemented in EAP peers . As such , we believe that this section contains minimal new interoperability or implementation requirements on EAP peers and can be applied to earlier versions of TLS . 
 Fixed in -17 
 Section 5.6 add " An example of limiting network access would be to invoke a vendor 's walled garden or quarantine network functionality . " 
 PR addresses this issue . 
 Fixed in -17 
 TLS introduces some new handshake messages . In general , these will just be handled by the underlying TLS library . " TLS 1.3 introduces several new handshake messages including HelloRetryRequest , NewSessionTicket , KeyUpdate . In general , these messages will be handled by the underlying TLS libraries and are not visible to EAP - TLS , however there are a few things to note . The HelloRetryRequest is used by the server to reject the parameters offered in the ClientHello and suggest new parameters . When this message is encountered it will increase the number of round trips used by the protocol . The NewSessionTicket message is used to convey session resumption information and is covered in sections 2.1.2 and 2.1.3 . The KeyUpdate message is used to update the encryption keys used on a TLS connection . EAP - TLS does not encrypt significant amounts of this data so this functionality is not needed . Implementations SHOULD NOT send this message , however some TLS libraries may automatically generate and process this message . ( remove current text on KeyUpdate ) Early Data MUST NOT be used in EAP - TLS . EAP - TLS servers MUST NOT send and early_data extension and clients MUST NOT send an EndOfEarlyData message . Servers MUST NOT use post handshake authentication . " 
 I made some minor rewording , plese check PR 
 This is addressed by PR 
 Fixed in -17 
 Most of the document applies only when TLS 1.3 is negotiated . The document should make clear that this is the case and explicitly point out areas that are applicable to earlier versions ( if any ) This issue was raised on the list be   and relates to issues raised by   as well . 
 Should any of this document apply to earlier versions of EAP - TLS or should it just apply to EAP - TLS when TLS 1.3 is negotiated . 
 Should any of this document apply to earlier versions of EAP - TLS or should it just apply to EAP - TLS when TLS 1.3 is negotiated . That was the intention from the beginning , but this is not true anymore because of Section 5.7 " Resumption " . " This is a new section when compared to [ RFC5216 ] . The guidance in this section is relevant for EAP - TLS in general ( regardless of the underlying TLS version used ) . " 
  with  regarding that " The only way this makes sense to me is if it is stated that should be explicitly stated . Howerer TLS 1.1 and TLS 1.0 should not be explicitly talked about as IETF has formally forbidden support . I 'll add something like " Except for Section 5.7 , this document applies only when TLS 1.3 is negotiated . When TLS 1.2 is negotiated , then RFC 5216 applies . " 
 As pointed out by  the draft should maybe also state " The EAP - TLS implementation does need to know which version of TLS is negotiated . " 
 This needed some additional changes as Section 2.2 according to applies to TLS 1.2 
 Fixed in -17 
 " TLS 1.3 significantly improves privacy when compared to earlier versions of TLS by forbidding cipher suites without confidentiality " This is not true as TLS 1.3 now has has cipher suites without confidentiality . Needs to be reformulated in terms of EAP - TLS 1.3 which states that confidentiality is mandated in another part of the document . -"EAP - TLS with TLS 1.3 exports the MSK and does not specify how it used by lower layers . " NIT should be " it is used " " EAP peers MAY implement a trust on first use ( TOFU ) mechanism where the peer trusts and stores the server certificate during the first connection attempt . The EAP peer ensures that the server presents the same stored certificate on subsequent interactions . Use of TOFU mechanism does not allow for the server certificate to change without out - of - band validation of the certificate and is therefore not suitable for many deployments . " This needs security considerations . 
 TLS 1.3 never forbade anything with respect to cipher suites . It just did n't define any . But I agree that the document should require cipher suites that provide confidentiality . Any suggestions for security considerations ? How about " TOFU mechanisms increase the susceptibility to traffic interception attacks and should only be used if there are adequate controls in place to mitigate this risk . " ? 
 Fixed in -17 
 Lets merge 83 and publish a new draft .
Paragraph (version A):
authorization and resumption for EAP-TLS in general (regardless of
the underlying TLS version used).  This document updates RFC 5216.
Paragraph (version B):
authentication, authorization, and resumption for EAP-TLS in general
(regardless of the underlying TLS version used).  This document
updates RFC 5216.
Paragraph (version A):
This document defines how to use EAP-TLS with TLS 1.3 and does not
change how EAP-TLS is used with older versions of TLS.  It does
however provide additional guidance on authorization and resumption
for EAP-TLS in general (regardless of the underlying TLS version
used).  While this document updates EAP-TLS RFC5216, it remains
backwards compatible with it and existing implementations of EAP-TLS.
This document only describes differences compared to RFC5216.  All
message flow are example message flows specific to TLS 1.3 and do not
apply to TLS 1.2.  Since EAP-TLS couples the TLS handshake state
machine with the EAP state machine it is possible that new versions
of TLS will cause incompatibilities that introduce failures or
security issues if they are not carefully integrated into the EAP-TLS
protocol.  Therefore, implementations MUST limit the maximum TLS
version they use to 1.3, unless later versions are explicitly enabled
by the administrator.
Paragraph (version B):
This document updates RFC5216 to define how to use EAP-TLS with TLS
maintain backwards compatibility.  However, this document does
provide additional guidance on authentication, authorization, and
resumption for EAP-TLS regardless of the underlying TLS version used.
This document only describes differences compared to RFC5216.  All
message flow are example message flows specific to TLS 1.3 and do not
apply to TLS 1.2.  Since EAP-TLS couples the TLS handshake state
machine with the EAP state machine it is possible that new versions
of TLS will cause incompatibilities that introduce failures or
security issues if they are not carefully integrated into the EAP-TLS
protocol.  Therefore, implementations MUST limit the maximum TLS
version they use to 1.3, unless later versions are explicitly enabled
by the administrator.
Paragraph (version A):
TLS 1.3 changes both the message flow and the handshake messages
compared to earlier versions of TLS.  Therefore, much of Section 2.1
of RFC5216 does not apply for TLS 1.3.  EAP-TLS 1.3 remains backwards
compatible with EAP-TLS 1.2 RFC5216 . TLS version negotiation is
handled by the TLS layer, and thus outside of the scope of EAP-TLS.
Therefore so long as the underlying TLS implementation correctly
implements TLS version negotiation, EAP-TLS will automatically
leverage that capability.
Paragraph (version B):
If the TLS implementation correctly implements TLS version
negotiation, EAP-TLS will automatically leverage that capability.
The EAP-TLS implementation needs to know which version of TLS was
negotiated to correctly support EAP-TLS 1.3 as well as to maintain
backward compatibility with EAP-TLS 1.2.
Paragraph (version B):
TLS 1.3 changes both the message flow and the handshake messages
compared to earlier versions of TLS.  Therefore, much of Section 2.1
of RFC5216 does not apply for TLS 1.3.  Except for Sections identity
and secres this document applies only when TLS 1.3 is negotiated.
When TLS 1.2 is negotiated, then RFC5216 applies.
Paragraph (version B):
The HelloRetryRequest is used by the server to reject the
parameters offered in the ClientHello and suggest new parameters.
When this message is encountered it will increase the number of
round trips used by the protocol.
Paragraph (version B):
The NewSessionTicket message is used to convey resumption
information and is covered in Sections ticket and resumption.
Paragraph (version B):
The KeyUpdate message is used to update the traffic keys used on a
TLS connection.  EAP-TLS does not encrypt significant amounts of
data so this functionality is not needed.  Implementations SHOULD
NOT send this message, however some TLS libraries may
automatically generate and process this message.
Paragraph (version B):
Early Data MUST NOT be used in EAP-TLS.  EAP-TLS servers MUST NOT
send an early_data extension and clients MUST NOT send an
EndOfEarlyData message.
Paragraph (version B):
Servers MUST NOT request post-handshake client authentication.
Paragraph (version A):
resumption.  TLS 1.3 introduced the Post-Handshake KeyUpdate message
which is not useful and not expected in EAP-TLS.  As a protected
success indication RFC3748 the EAP-TLS server always sends TLS
application data 0x00, see Section 2.5.  Note that a TLS
implementation MAY not allow the EAP-TLS layer to control in which
order things are sent and the application data MAY therefore be sent
before a NewSessionTicket.  TLS application data 0x00 is therefore to
be interpreted as success after the EAP-Request that contains TLS
application data 0x00.  After the EAP-TLS server has sent an EAP-
Request containing the TLS application data 0x00 and received an EAP-
Response packet of EAP-Type=EAP-TLS and no data, the EAP-TLS server
sends EAP-Success.
Paragraph (version B):
resumption.  As a protected success indication RFC3748 the EAP-TLS
server always sends TLS application data 0x00, see Section 2.5.  Note
that a TLS implementation MAY not allow the EAP-TLS layer to control
in which order things are sent and the application data MAY therefore
be sent before a NewSessionTicket.  TLS application data 0x00 is
therefore to be interpreted as success after the EAP-Request that
contains TLS application data 0x00.  After the EAP-TLS server has
sent an EAP-Request containing the TLS application data 0x00 and
received an EAP-Response packet of EAP-Type=EAP-TLS and no data, the
EAP-TLS server sends EAP-Success.
Paragraph (version A):
This section updates Section 2.2 of RFC5216.
Paragraph (version B):
This section updates Section 2.2 of RFC5216.  The guidance in this
section is relevant for EAP-TLS in general (regardless of the
underlying TLS version used).
Paragraph (version A):
for EAP authentication by the Peer.
Paragraph (version B):
for EAP authentication by the Peer.  While this requirement to verify
domain names is new, and was not mentioned in RFC5216, it has been
widely implemented in EAP-TLS peers.  As such, it is believed that
this section contains minimal new interoperability or implementation
requirements on EAP-TLS peers and can be applied to earlier versions
of TLS.
Paragraph (version A):
availability.
Paragraph (version B):
availability.  TOFU mechanisms increase the susceptibility to traffic
interception attacks and should only be used if there are adequate
controls in place to mitigate this risk.
Paragraph (version A):
When EAP-TLS is used with TLS version 1.3 the Key_Material and
Method-Id SHALL be derived from the exporter_secret using the TLS
exporter interface RFC5705 (for TLS 1.3 this is defined in
Section 7.5 of RFC8446).
Paragraph (version B):
When EAP-TLS is used with TLS version 1.3 the Key_Material and
Method-Id SHALL be derived from the exporter_secret using the TLS
exporter interface RFC5705 (for TLS 1.3 this is defined in
Section 7.5 of RFC8446).  Type is the value of the EAP Type field
defined in Section 2 of RFC3748.  For EAP-TLS the Type field has
value 0x0D.
Paragraph (version A):
No updates to section 5.2 of RFC5216.
Paragraph (version B):
No updates to section 5.2 of RFC5216.  Note that identity has
additional discussion on identities.
Paragraph (version A):
While certificates may have long validity periods, there are a number
of reasons (e.g., key compromise, CA compromise, privilege withdrawn,
etc.) why EAP-TLS peer, EAP-TLS server, or sub-CA certificates have
to be revoked before their expiry date.  Revocation of the EAP-TLS
server's certificate is complicated by the fact that the EAP-TLS peer
may not have Internet connectivity until authentication completes.
Paragraph (version B):
There are a number of reasons (e.g., key compromise, CA compromise,
privilege withdrawn, etc.) why EAP-TLS peer, EAP-TLS server, or sub-
CA certificates have to be revoked before their expiry date.
Revocation of the EAP-TLS server's certificate is complicated by the
fact that the EAP-TLS peer may not have Internet connectivity until
authentication completes.
Paragraph (version A):
EAP servers will usually require the EAP peer to provide a valid
certificate and will fail the connection if one is not provided.
Some deployments may permit no peer authentication for some or all
connections.  When peer authentication is not used, EAP-TLS server
implementations MUST take care to limit network access appropriately
for unauthenticated peers and implementations MUST use resumption
with caution to ensure that a resumed session is not granted more
privilege than was intended for the original session.
Paragraph (version B):
EAP servers will usually require the EAP peer to provide a valid
certificate and will fail the connection if one is not provided.
Some deployments may permit no peer authentication for some or all
connections.  When peer authentication is not used, EAP-TLS server
implementations MUST take care to limit network access appropriately
for unauthenticated peers and implementations MUST use resumption
with caution to ensure that a resumed session is not granted more
privilege than was intended for the original session.  An example of
limiting network access would be to invoke a vendor's walled garden
or quarantine network functionality.
Paragraph (version A):
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
EAP-TLS server need to be able to securely retrieve authorization
information such as certificate chains from the initial full
handshake.  We use the term "cached data" to describe such
information.  Authorization during resumption MUST be based on such
cached data.  The EAP-TLS peer and EAP-TLS server MAY perform fresh
revocation checks on the cached certificate data.  Any security
policies for authorization MUST be followed also for resumption.  The
certificates may have been revoked since the initial full handshake
and the authorizations of the other party may have reduced.  If the
cached revocation data is not sufficiently current, the EAP-TLS peer
or EAP-TLS server MAY force a full TLS handshake.
Paragraph (version B):
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
EAP-TLS server need to be able to securely retrieve authorization
information such as certificate chains from the initial full
handshake.  This document use the term "cached data" to describe such
information.  Authorization during resumption MUST be based on such
cached data.  The EAP-TLS peer and EAP-TLS server MAY perform fresh
revocation checks on the cached certificate data.  Any security
policies for authorization MUST be followed also for resumption.  The
certificates may have been revoked since the initial full handshake
and the authorizations of the other party may have reduced.  If the
cached revocation data is not sufficiently current, the EAP-TLS peer
or EAP-TLS server MAY force a full TLS handshake.
Paragraph (version A):
If the EAP-TLS server or EAP client do not apply any authorization
policies, they MAY allow resumption where no cached data is
available.  In all other cases, they MUST cache data during the
initial full handshake to enable resumption.  The cached data MUST be
sufficient to make authorization decisions during resumption.  If
cached data cannot be retrieved in a secure way, resumption MUST NOT
be done.
Paragraph (version B):
The EAP-TLS server or EAP client MUST cache data during the initial
full handshake sufficient to allow authorization decisions to be made
during resumption.  If cached data cannot be retrieved in a secure
way, resumption MUST NOT be done.