Subject: Re: [Emu] FW: New Version Notification for draft-ietf-emu-eap-tls13-03.txt

From: "Cappalli, Tim (Aruba Security)" <[email-masked]>
Date: Wed, 14 Nov 2018 13:16:13 +0000

Making it mandatory to use an anonymous NAI will be a huge issue in enterprise where the infrastructure, device and enterprise identity is owned by the enterprise. There is no proxy or third party provider.

Seeing "[email-masked]" across all network infrastructure is not going to be acceptable.

Why not provide a flag that can be passed in the EAP exchange from the supplicant that enables this behavior so users with full control of their device can use this while enterprise or other use cases that require real identity can configure the supplicant to provide a different flag?

tim

On 11/14/18, 7:50 AM, "Emu on behalf of John Mattsson" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,
    
    We have updated the draft according to the discussion and conclusions at IETF 103. 
    
    - New figure showing the message flow for EAP-TLS client rejection of NewSessionTicket	
    
    - The draft did not mention that TLS has both warning and fatal alerts. We changed "TLS Alert Message" to " TLS Fatal Alert" and added a few sentences that describe the difference.
    
      "Figures 4, 5, 6, and 7 illustrate message flows in several cases	
       where the EAP peer or EAP server sends a TLS fatal alert message.	
       TLS warning alerts generally mean that the connection can continue	
       normally and does not change the message flow.  Note that the party	
       receiving a TLS warning alert may choose to terminate the connection	
       by sending a TLS fatal alert, which may add an extra round-trip, see	
       [RFC8446]."
    
    - Made it mandatory to always conceal the username in the Identity Response. This led to smaller changes in several places.
       -- Text were updated to reflect this is mandatory 
       -- Changed "Identity (MyID)" to "Identity (Anonymous NAI)" in all figures
       -- Removed the "privacy" figure as that is no longer needed. Instead the section refer to Figure 1.
    
    - Added "and all Post-Handshake messages have been sent" to page 3. The new sentence reads:
     "After the TLS handshake has completed and all Post-Handshake messages have been sent, the EAP server sends EAP-Success."	
    
    - Several editorials.
    
    Cheers,
    John
    
    -----Original Message-----
    From: "[email-masked]" <[email-masked]>
    Date: Wednesday, 14 November 2018 at 13:20
    To: Mohit Sethi <[email-masked]>, John Mattsson <[email-masked]>
    Subject: New Version Notification for draft-ietf-emu-eap-tls13-03.txt

    A new version of I-D, draft-ietf-emu-eap-tls13-03.txt
    has been successfully submitted by John Mattsson and posted to the
    IETF repository.
    
    Name:		draft-ietf-emu-eap-tls13
    Revision:	03
    Title:		Using EAP-TLS with TLS 1.3
    Document date:	2018-11-14
    Group:		emu
    Pages:		22
    URL:            https://www.ietf.org/internet-drafts/draft-ietf-emu-eap-tls13-03.txt
    Status:         https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/
    Htmlized:       https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-03
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13
    Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-03
    
    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 provides significantly improved protection against
       pervasive monitoring by mandating use of privacy.  This document
       updates RFC 5216.

    
    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org.
    
    The IETF Secretariat

    _______________________________________________
    Emu mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/emu

---

From: Alan DeKok <[email-masked]>
Date: Wed, 14 Nov 2018 08:37:48 -0500

> Making it mandatory to use an anonymous NAI will be a huge issue in enterprise where the infrastructure, device and enterprise identity is owned by the enterprise. There is no proxy or third party…

 I don't see that in Section 2.1.4.  It says:

   ... a client supporting TLS 1.3 MUST NOT send its
   username in cleartext in the Identity Response.  It is RECOMMENDED to
   use anonymous NAIs, but other solutions where the username is
   encrypted MAY be used.

  So username *hiding* his mandatory.  But the method is left to the implementation.

> Seeing "[email-masked]" across all network infrastructure is not going to be acceptable.

  In what context will you "see" that across all network infrastructure?

  Since this is the enterprise, you control your own RADIUS server.  You can associate the *inner* identity with the users session.  There is no requirement that you only look at the outer identity for tracking user sessions.  This tying of inner / outer identities is common in ISP and enterprise environments.

  In the absence of specific reasons behind this statement, I just don't see how anonymous identities are a problem for anyone, anywhere.

  If I had to guess, I'd say that the problem comes from *other* devices on the network.  Devices that snoop EAP, but aren't involved in the actual authentication.  The solution there would be to have the local RADIUS server talk to the local snooping device.  Or, the local snooping device looks at MAC addresses instead of EAP identities.  And then uses the RADIUS DB to correlate MAC address to EAP inner identity. 

> Why not provide a flag that can be passed in the EAP exchange from the supplicant that enables this behavior so users with full control of their device can use this while enterprise or other use ca…

  Given the horrific nature of implementations and inter-operability, I would oppose yet another point of negotiation.  It does not add anything IMHO.  And, it makes implementations and inter-operability more complex.

  Alan DeKok.

---

From: "Cappalli, Tim (Aruba Security)" <[email-masked]>
Date: Wed, 14 Nov 2018 14:48:53 +0000

The question was asked about making it anonymous NAI mandatory in the Identity Response. That is what my comments were targeted to.

In terms of infrastructure, logging into a wireless controller, switch or NMS and seeing hundreds of "[email-masked]" makes an administrator's life miserable. Most folks in a large enterprise responsible for troubleshooting end user access do not have access to the EAP server.

The only way to provide the real identity back to the NAS would be sending it back as the IETF User-Name in the Access-Accept with the assumption that the NAS would honor it. 

tim

On 11/14/18, 8:38 AM, "Alan DeKok" <[email-masked]> wrote:

    On Nov 14, 2018, at 8:16 AM, Cappalli, Tim (Aruba Security) <[email-masked]> wrote:

       encrypted MAY be used.

      Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 14 Nov 2018 10:45:20 -0500

> The question was asked about making it anonymous NAI mandatory in the Identity Response. That is what my comments were targeted to.

  OK.

  For me, I would be fine with making the anonymous NAI mandatory.  I just don't see any end-user benefit to exposing their identities.  And there are benefits to privacy.

> In terms of infrastructure, logging into a wireless controller, switch or NMS and seeing hundreds of "[email-masked]" makes an administrator's life miserable. Most folks in a large enterprise respo…

  If I were hard-nosed, I would say that's an internal management issue, and not a standards issue.  But I get your point, and there are ways to address this (see below).

> The only way to provide the real identity back to the NAS would be sending it back as the IETF User-Name in the Access-Accept with the assumption that the NAS would honor it. 

  All NASes that I'm aware of support this.  i.e. where the User-Name in Access-Accept is *not* the same as the one in the Access-Request.

  This question came up recently on RADEXT.  The thread is here:

https://www.ietf.org/mail-archive/web/radext/current/msg10079.html

  In short, it is possible (and is widely used) to return the *inner* EAP-TLS identity in the *outer* RADIUS Access-Accept.  That breaks user anonymity, but it definitely works.

  My $0.02 is that we *should* mandate anonymous outer identities.  Enterprises which are OK with breaking user privacy can return a different User-Name in the Access-Accept.  Other systems can use another method to track user identities across a session.

  In a related note, RFC 4372 defines a "Chargable-User-Identity" which is intended to be used as an anonymized user identity in roaming situations.  In practice, it's only really supported in WiMAX and in some 3G situations.  Most enterprise equipment does not support it, which makes it inapplicable here.

  Never the less, something similar could be done with User-Name in the Access-Accept.  And, it should  be supported by all enterprise equipment.

  It may be useful to discuss these topics in a "best practices" document for EAP and user anonymity.  If the WG thinks it's useful, I could write it.

  Alan DeKok.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Nov 2018 11:12:09 -0500

Alan DeKok <[email-masked]> wrote:
    > For me, I would be fine with making the anonymous NAI mandatory.  I
    > just don't see any end-user benefit to exposing their identities.  And
    > there are benefits to privacy.

    >> In terms of infrastructure, logging into a wireless controller, switch
    >>or NMS and seeing hundreds of "[email-masked]" makes an
    >>administrator's life miserable. Most folks in a large enterprise
    >>responsible for troubleshooting end user access do not have access to
    >>the EAP server.

    > If I were hard-nosed, I would say that's an internal management issue,
    > and not a standards issue.  But I get your point, and there are ways to
    > address this (see below).

It might be a lack of standard way to access logs of EAP server issue.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Jim Schaad <[email-masked]>
Date: Wed, 14 Nov 2018 10:34:54 -0800

> From: Emu <[email-masked]> On Behalf Of Cappalli, Tim (Aruba
> Security)
> Sent: Wednesday, November 14, 2018 6:49 AM
> To: Alan DeKok <[email-masked]>
> Cc: [email-masked]; John Mattsson <[email-masked]>
> Subject: Re: [Emu] FW: New Version Notification for draft-ietf-emu-eap-
> tls13-03.txt
> 
> The question was asked about making it anonymous NAI mandatory in the
> Identity Response. That is what my comments were targeted to.
> 
> In terms of infrastructure, logging into a wireless controller, switch or NMS
> and seeing hundreds of "[email-masked]" makes an
> administrator's life miserable. Most folks in a large enterprise responsible for
> troubleshooting end user access do not have access to the EAP server.
> 
> The only way to provide the real identity back to the NAS would be sending it
> back as the IETF User-Name in the Access-Accept with the assumption that
> the NAS would honor it.

My first response to this would be - what happens as an attacker I supply one name in the outer and validate using a different (and correct) inner name.  This is going to make the administrator's life miserable since they are going to be looking at the wrong name and not have any ability to recognize that that is the problem.

Jim

>     > Making it mandatory to use an anonymous NAI will be a huge issue in
> enterprise where the infrastructure, device and enterprise identity is owned
> by the enterprise. There is no proxy or third party provider.
> 
> 
> 
>       Since this is the enterprise, you control your own RADIUS server.  You can
> associate the *inner* identity with the users session.  There is no
> requirement that you only look at the outer identity for tracking user
> sessions.  This tying of inner / outer identities is common in ISP and
> enterprise environments.
> 
> 
> 
>       In the absence of specific reasons behind this statement, I just don't see
> how anonymous identities are a problem for anyone, anywhere.
> 
> 
> 
>       If I had to guess, I'd say that the problem comes from *other* devices on
> the network.  Devices that snoop EAP, but aren't involved in the actual
> authentication.  The solution there would be to have the local RADIUS server
> talk to the local snooping device.  Or, the local snooping device looks at MAC
> addresses instead of EAP identities.  And then uses the RADIUS DB to
> correlate MAC address to EAP inner identity.
> 
> 
> 
>     > Why not provide a flag that can be passed in the EAP exchange from the
> supplicant that enables this behavior so users with full control of their device
> can use this while enterprise or other use cases that require real identity can
> configure the supplicant to provide a different flag?
> 
> 
> 
>       Given the horrific nature of implementations and inter-operability, I
> would oppose yet another point of negotiation.  It does not add anything
> IMHO.  And, it makes implementations and inter-operability more complex.
> 
> 
> 
>       Alan DeKok.
> 
> 
> 
>

---

From: Alan DeKok <[email-masked]>
Date: Wed, 14 Nov 2018 15:27:00 -0500

On Nov 14, 2018, at 1:34 PM, Jim Schaad <[email-masked]> wrote:
> My first response to this would be - what happens as an attacker I supply one name in the outer and validate using a different (and correct) inner name.

  That happens all of the time.  Users are inventive with methods of avoiding payment.

>  This is going to make the administrator's life miserable since they are going to be looking at the wrong name and not have any ability to recognize that that is the problem.

  The better solution (and one implemented by most people), is have the authentication server check for this situation.  And, reject authentications that have mismatched identities.

  For some discussion of this subject, see:

https://tools.ietf.org/html/rfc7542#section-4.2

  It would help for the Security Considerations section of the EAP-TLS 1.3 document to have additional discussion and clarifications of this topic.  It should at least note that the inner and outer identities can be different, and reference Section 4.2 of RFC 7542.

  For an implementation of inner/outer identity checks, see:

https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/policy.d/filter#L111

  It's not perfect, but it seems to work well in practice.

  Alan DeKok.

---

From: Jim Schaad <[email-masked]>
Date: Wed, 14 Nov 2018 13:29:01 -0800

This message had my response in the wrong place.  I was responding to Tim's comments and not to Alan's comments.  I completely agree with Alan that this information needs to be fed back to the NAS and not rely on what the client starts out saying.

> From: Emu <[email-masked]> On Behalf Of Jim Schaad
> Sent: Wednesday, November 14, 2018 10:35 AM
> To: 'Cappalli, Tim (Aruba Security)' <[email-masked]>; 'Alan DeKok'
> <[email-masked]>
> Cc: [email-masked]; 'John Mattsson' <[email-masked]>
> > Subject: Re: [Emu] FW: New Version Notification for
> > draft-ietf-emu-eap- tls13-03.txt
> >
> > responsible for troubleshooting end user access do not have access to the
> EAP server.
> >
> > The only way to provide the real identity back to the NAS would be
> > sending it back as the IETF User-Name in the Access-Accept with the
> > assumption that the NAS would honor it.
> 
> My first response to this would be - what happens as an attacker I supply one
> name in the outer and validate using a different (and correct) inner name.
> This is going to make the administrator's life miserable since they are going
> to be looking at the wrong name and not have any ability to recognize that
> that is the problem.
> 
> Jim
> 
> >
> > tim
> >
> >     > Making it mandatory to use an anonymous NAI will be a huge issue
> > in enterprise where the infrastructure, device and enterprise identity
> > is owned by the enterprise. There is no proxy or third party provider.
> >
> >
> >
> >     > Seeing "[email-masked]" across all network
> > infrastructure is not going to be acceptable.
> >
> >
> >
> >       Since this is the enterprise, you control your own RADIUS
> > server.  You can associate the *inner* identity with the users
> > session.  There is no requirement that you only look at the outer
> > identity for tracking user sessions.  This tying of inner / outer
> > identities is common in ISP and enterprise environments.
> >
> >
> >
> >       In the absence of specific reasons behind this statement, I just
> > don't see how anonymous identities are a problem for anyone, anywhere.
> >
> >
> >
> >       If I had to guess, I'd say that the problem comes from *other*
> > devices on the network.  Devices that snoop EAP, but aren't involved
> > in the actual authentication.  The solution there would be to have the
> > local RADIUS server talk to the local snooping device.  Or, the local
> > snooping device looks at MAC addresses instead of EAP identities.  And
> > then uses the RADIUS DB to correlate MAC address to EAP inner identity.
> >
> >
> >
> >     > Why not provide a flag that can be passed in the EAP exchange
> > from the supplicant that enables this behavior so users with full
> > control of their device can use this while enterprise or other use
> > cases that require real identity can configure the supplicant to provide a
> different flag?
> >
> >
> >
> >       Given the horrific nature of implementations and
> > inter-operability, I would oppose yet another point of negotiation.
> > It does not add anything IMHO.  And, it makes implementations and inter-
> operability more complex.
> >
> >
> >
> >       Alan DeKok.
> >
> >
> >
> >
> 
>

---

From: "Dr. Pala" <[email-masked]>
Date: Wed, 21 Nov 2018 08:36:25 -0700

Hi all,

in other environment we had to add the attribute about which ID was 
actually authenticated in the final messages because of additional 
operations that some network equipment needs to perform that requires 
the identity of the supplicant to be disclosed (exactly to avoid the use 
of an external identity and different credentials when authenticating).

I just want to point out the obvious - this is a sub-case of the 
anonymous NAI format. If there is any consensus in mandating for that 
format/identity then we need to mandate that the authenticated identity 
is carried in the accept/success message (which could still be the 
anonymous NAI format if the system allows that to be a valid identity 
value).

Does that make sense ?

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Alan DeKok <[email-masked]>
Date: Wed, 21 Nov 2018 10:52:17 -0500

On Nov 21, 2018, at 10:36 AM, Dr. Pala <[email-masked]> wrote:
> 
> in other environment we had to add the attribute about which ID was actually authenticated in the final messages because of additional operations that some network equipment needs to perform that requires the identity of the supplicant to be disclosed (exactly to avoid the use of an external identity and different credentials when authenticating).

  Which attribute was that?

> I just want to point out the obvious - this is a sub-case of the anonymous NAI format. If there is any consensus in mandating for that format/identity then we need to mandate that the authenticated identity is carried in the accept/success message (which could still be the anonymous NAI format if the system allows that to be a valid identity value).

  I would suggest the following requirements:

* it is useful to track the authenticated user
* it would be good to keep user privacy while doing this (i.e. *not* exposing the inner identity)
* using anything *other* than the NAI format for tracking will break many things

  For example, we have a user who logs with anonymous identity as "@example.com", and real identity as "[email-masked]".  We then require that any anonymised "tracking" identity MUST be within the domain of example.com.

  The reason is that the User-Name sent in Access-Accept will be used for subsequent accounting packets.  In a roaming environment, these accounting packets MUST be routable to the same destination as was used for authentication.

  We are then left with making recommendations for NAIs that are within the namespace of a particular domain.  i.e. telling "example.com" what they should or should not use for these anonymous identities.  RFC 7542 was *very* careful in not making such recommendations.  It's just too hard to make recommendations that everyone can accept, much less use.

  To throw out an idea, IMHO the only safe recommendation is to use the MAC address of the device as the users anonymized "identity".  The MAC address is already public to participants in EAP / RADIUS (via Calling-Station-Id).  It's already globally unique (via IEEE requirements).  So it would seem to not only work, but satisfy the requirements I noted above.

  Using the MAC address doesn't help in the situation that Tim Cappalli noted.  But we care less about privacy within an enterprise environment.  Those situations can just expose the inner identity, and be done with it.

  So we're left with recommending "MAC-ADDRESS@realm".   Maybe also recommending "[email-masked]". in order to separate the namespaces of "real" identities, and "anonymized" identities.

  Comments?

  Alan DeKok.