Alan DeKok <al...@deployingradius.com>;; wrote:

 >This security bug was completely missed in RFC 5216.  This new draft should 
 >rectify that error.
>
 >i.e. using an NAI of "example.org" in the first session, and "example.com" in 
 >the second session.
>
 >Not only is this entirely permitted by the current spec, it's not even 
 >discussed as an issue.  And it means that the protocol is open to a large 
 >number of time of use, time of check" security bugs which could cause serious 
 >breaches of networks.

I think Section 2.2 of RFC 5216 do discuss this issue, but it does not 
explicitly mention resumption. The text is also too soft. 

----------------
 2.2.  Identity Verification

   As noted in Section 5.1 of [RFC3748]:

      It is RECOMMENDED that the Identity Response be used primarily for
      routing purposes and selecting which EAP method to use.  EAP
      Methods SHOULD include a method-specific mechanism for obtaining
      the identity, so that they do not have to rely on the Identity
      Response.

   As part of the TLS negotiation, the server presents a certificate to
   the peer, and if mutual authentication is requested, the peer
   presents a certificate to the server.  EAP-TLS therefore provides a
   mechanism for determining both the peer identity (Peer-Id in
   [KEYFRAME]) and server identity (Server-Id in [KEYFRAME]).  For
   details, see Section 5.2.

   Since the identity presented in the EAP-Response/Identity need not be
   related to the identity presented in the peer certificate, EAP-TLS
   implementations SHOULD NOT require that they be identical.  However,
   if they are not identical, the identity presented in the EAP-
   Response/Identity is unauthenticated information, and SHOULD NOT be
   used for access control or accounting purposes.
----------------

Suggestion to add to Section 2.2 of EAP-TLS 1.3

"The identity presented in the EAP-Response/Identity is unauthenticated 
information, and SHALL NOT be used for access control or accounting purposes. 
Note that this also applies to resumption."

/John

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

Reply via email to