Re: [Emu] FW: New Version Notification for draft-ietf-emu-eap-tls13-03.txt
On Nov 21, 2018, at 10:36 AM, Dr. Pala 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 "b...@example.com". 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 "MAC-ADDRESS@anonymous.realm". in order to separate the namespaces of "real" identities, and "anonymized" identities. Comments? Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] FW: New Version Notification for draft-ietf-emu-eap-tls13-03.txt
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 On 11/14/18 2:29 PM, Jim Schaad wrote: 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. -Original Message- From: Emu On Behalf Of Jim Schaad Sent: Wednesday, November 14, 2018 10:35 AM To: 'Cappalli, Tim (Aruba Security)' ; 'Alan DeKok' Cc: emu@ietf.org; 'John Mattsson' Subject: Re: [Emu] FW: New Version Notification for draft-ietf-emu-eap- tls13-03.txt -Original Message- From: Emu On Behalf Of Cappalli, Tim (Aruba Security) Sent: Wednesday, November 14, 2018 6:49 AM To: Alan DeKok Cc: emu@ietf.org; John Mattsson 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 "anonym...@enterprise.co" 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 tim On 11/14/18, 8:38 AM, "Alan DeKok" wrote: On Nov 14, 2018, at 8:16 AM, Cappalli, Tim (Aruba Security) wrote: > > 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. 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 "anonym...@enterprise.com" 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 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 mor
Re: [Emu] FW: New Version Notification for draft-ietf-emu-eap-tls13-03.txt
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. > -Original Message- > From: Emu On Behalf Of Jim Schaad > Sent: Wednesday, November 14, 2018 10:35 AM > To: 'Cappalli, Tim (Aruba Security)' ; 'Alan DeKok' > > Cc: emu@ietf.org; 'John Mattsson' > Subject: Re: [Emu] FW: New Version Notification for draft-ietf-emu-eap- > tls13-03.txt > > > > > -Original Message- > > From: Emu On Behalf Of Cappalli, Tim (Aruba > > Security) > > Sent: Wednesday, November 14, 2018 6:49 AM > > To: Alan DeKok > > Cc: emu@ietf.org; John Mattsson > > 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 "anonym...@enterprise.co" 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 > > > > > tim > > > > On 11/14/18, 8:38 AM, "Alan DeKok" > wrote: > > > > > > > > On Nov 14, 2018, at 8:16 AM, Cappalli, Tim (Aruba Security) > > wrote: > > > > > > > > > > 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. > > > > > > > > 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 "anonym...@enterprise.com" 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 > > 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. > > > > > > > > > > > ___ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] FW: New Version Notification for draft-ietf-emu-eap-tls13-03.txt
On Nov 14, 2018, at 1:34 PM, Jim Schaad wrote: >> 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. 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. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] FW: New Version Notification for draft-ietf-emu-eap-tls13-03.txt
> -Original Message- > From: Emu On Behalf Of Cappalli, Tim (Aruba > Security) > Sent: Wednesday, November 14, 2018 6:49 AM > To: Alan DeKok > Cc: emu@ietf.org; John Mattsson > 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 "anonym...@enterprise.co" 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 > > tim > > On 11/14/18, 8:38 AM, "Alan DeKok" wrote: > > > > On Nov 14, 2018, at 8:16 AM, Cappalli, Tim (Aruba Security) > wrote: > > > > > > 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. > > > > 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 "anonym...@enterprise.com" 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 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. > > > > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] FW: New Version Notification for draft-ietf-emu-eap-tls13-03.txt
Alan DeKok 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 "anonym...@enterprise.co" 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 , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] FW: New Version Notification for draft-ietf-emu-eap-tls13-03.txt
On Nov 14, 2018, at 9:48 AM, Cappalli, Tim (Aruba Security) wrote: > > 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 "anonym...@enterprise.co" 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). > 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. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
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 "anonym...@enterprise.co" 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" wrote: On Nov 14, 2018, at 8:16 AM, Cappalli, Tim (Aruba Security) wrote: > > 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. 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 "anonym...@enterprise.com" 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 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. smime.p7s Description: S/MIME cryptographic signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] FW: New Version Notification for draft-ietf-emu-eap-tls13-03.txt
On Nov 14, 2018, at 8:16 AM, Cappalli, Tim (Aruba Security) wrote: > > 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. 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 "anonym...@enterprise.com" 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 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. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] FW: New Version Notification for draft-ietf-emu-eap-tls13-03.txt
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 "anonym...@enterprise.com" 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" 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: "internet-dra...@ietf.org" Date: Wednesday, 14 November 2018 at 13:20 To: Mohit Sethi , John Mattsson 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 Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] FW: New Version Notification for draft-ietf-emu-eap-tls13-03.txt
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: "internet-dra...@ietf.org" Date: Wednesday, 14 November 2018 at 13:20 To: Mohit Sethi , John Mattsson 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 Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
