Re: [TLS] [Emu] Underspecification of EAP-TLS 1.3 State Machine
Thanks Mohit, Based on your comments it seems like protected success indication is not needed in IEEE 802 for security reasons. Would be good with more feedback on this. EAP-TLS 1.3 might get a protected success indication anyway, but the draft should have a few sentences about what the alternate success indication is good for. Would also be good to conclude that other methods do not need an alternate success indication. Seems like e.g. RFC 5448 removed the optional result indications from RFC 4187, probably after an agreement that they were not needed. Note that RFC 4137 is informal and not mandatory to follow. Similarly a implementation can ignore the alternative success indication unless EAP-TLS 1.3 makes it mandatory. In RFC 5216 it is to my understanding up to the implementation if it wants to use server Finished as a alternate success indication. Cheers, John From: Mohit Sethi M Date: Monday, 8 February 2021 at 06:33 To: John Mattsson , Bernard Aboba , "e...@ietf.org" , "TLS@ietf.org" Subject: Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine Hi all, I have now read both the papers. I am not sure the attacks in [2] are anymore possible: - The first attack described in section 4.1.1 shows that an EAP-Success leads to an unconditional transition to the Authenticated state irrespective of the current state. However, I am not sure this is the case anymore as RFC 4137 (https://tools.ietf.org/html/rfc4137#appendix-A.1) now says : |+-- | rxSuccess && | | (reqId == lastId) && | SUCCESS | (decision != FAIL) | |+-- The peer cannot simply transition to SUCCESS state as the decision is initialized to FAIL. The decision is set to COND_SUCC or UNCOND_SUCC only after the peer decides that the server has sufficiently been authenticated (for EAP methods with mutual authentication). - The second attack described in section 4.2 relies on the adversary sending a disassociate management frame and then uses the MAC address of the authenticated supplicant to gain network access. This again should not work as a) 802.11w-2009 protects disassociate management frame, and b) EAP-Success is followed by 4-way handshake after which there is per packet authenticity and integrity (with Key Confirmation Key). The attacker cannot gain network access without knowing the PMK (derived from the MSK) and performing the 4-way handshake. The attacks in [1] are not specific to EAP. The attacks relate to Denial of Service (DoS) by injecting spoofed alerts in TLS. John has suggested the following text for the draft (which I think is sufficient): Protected TLS Error alerts are protected failure result indications and enables the EAP-TLS peer and EAP-TLS server to determine that the failure result was not spoofed by an attacker. Protected failure result indications provide integrity protection and replay but MAY be unauthenticated. Protected failure result does not significantly improve availability as TLS 1.3 treats most malformed data as a fatal error. --Mohit [1] Extensible Authentication Protocol Vulnerabilities and Improvements : https://scholarworks.sjsu.edu/cgi/viewcontent.cgi?article=1431&context=etd_projects [2] An Initial Security Analysis of the IEEE 802.1X Standard : http://www.cs.cornell.edu/people/egs/615/mishra-arbaugh.pdf On 2/4/21 2:18 PM, John Mattsson wrote: Hi Bernard, I (re-)read the papers you send. - "Extensible Authentication Protocol Vulnerabilities and Improvements Improvements" This paper talks attacks on availability by spoofing messages. It looks into a small amount of ways where spoofed messages causes the TLS connection to fail, especially it focus on alert messages. TLS and EAP-TLS is trivial for an on-path attacker to shut down. Basically any small error is fatal in TLS. Focusing on alert messages does not seem correct. An attacker can e.g. at any time send a small record with length 2^15, which causes TLS to terminate the connection. I think the only thing that can be achieved without rewriting TLS is that availability attacks does not cause long-term damage, i.e. the nodes can retry the handshake. - "An Initial Security Analysis of the IEEE 802.1X Standard" This paper discusses attacks on 801.11. The weaknesses described seems to come from 802.11 / EAP interactions. The discussions around IETF 102 was that the uncertainty (NewSessionTicket or not) in TLS 1.3 was "inconvinient" and that it would be convient to get rid of the uncertainty. Bernard then pointed out that any message changing the state need to be authenticated to that it is not possible to spoof. I think that both the application layer commit message as well as close_notify fulfill these old requirements. I think your analysis
Re: [TLS] [Emu] Underspecification of EAP-TLS 1.3 State Machine
Hi all, I have now read both the papers. I am not sure the attacks in [2] are anymore possible: - The first attack described in section 4.1.1 shows that an EAP-Success leads to an unconditional transition to the Authenticated state irrespective of the current state. However, I am not sure this is the case anymore as RFC 4137 (https://tools.ietf.org/html/rfc4137#appendix-A.1) now says : |+-- | rxSuccess && | | (reqId == lastId) && | SUCCESS | (decision != FAIL) | |+-- The peer cannot simply transition to SUCCESS state as the decision is initialized to FAIL. The decision is set to COND_SUCC or UNCOND_SUCC only after the peer decides that the server has sufficiently been authenticated (for EAP methods with mutual authentication). - The second attack described in section 4.2 relies on the adversary sending a disassociate management frame and then uses the MAC address of the authenticated supplicant to gain network access. This again should not work as a) 802.11w-2009 protects disassociate management frame, and b) EAP-Success is followed by 4-way handshake after which there is per packet authenticity and integrity (with Key Confirmation Key). The attacker cannot gain network access without knowing the PMK (derived from the MSK) and performing the 4-way handshake. The attacks in [1] are not specific to EAP. The attacks relate to Denial of Service (DoS) by injecting spoofed alerts in TLS. John has suggested the following text for the draft (which I think is sufficient): Protected TLS Error alerts are protected failure result indications and enables the EAP-TLS peer and EAP-TLS server to determine that the failure result was not spoofed by an attacker. Protected failure result indications provide integrity protection and replay but MAY be unauthenticated. Protected failure result does not significantly improve availability as TLS 1.3 treats most malformed data as a fatal error. --Mohit [1] Extensible Authentication Protocol Vulnerabilities and Improvements : https://scholarworks.sjsu.edu/cgi/viewcontent.cgi?article=1431&context=etd_projects [2] An Initial Security Analysis of the IEEE 802.1X Standard : http://www.cs.cornell.edu/people/egs/615/mishra-arbaugh.pdf On 2/4/21 2:18 PM, John Mattsson wrote: Hi Bernard, I (re-)read the papers you send. - "Extensible Authentication Protocol Vulnerabilities and Improvements Improvements" This paper talks attacks on availability by spoofing messages. It looks into a small amount of ways where spoofed messages causes the TLS connection to fail, especially it focus on alert messages. TLS and EAP-TLS is trivial for an on-path attacker to shut down. Basically any small error is fatal in TLS. Focusing on alert messages does not seem correct. An attacker can e.g. at any time send a small record with length 2^15, which causes TLS to terminate the connection. I think the only thing that can be achieved without rewriting TLS is that availability attacks does not cause long-term damage, i.e. the nodes can retry the handshake. - "An Initial Security Analysis of the IEEE 802.1X Standard" This paper discusses attacks on 801.11. The weaknesses described seems to come from 802.11 / EAP interactions. The discussions around IETF 102 was that the uncertainty (NewSessionTicket or not) in TLS 1.3 was "inconvinient" and that it would be convient to get rid of the uncertainty. Bernard then pointed out that any message changing the state need to be authenticated to that it is not possible to spoof. I think that both the application layer commit message as well as close_notify fulfill these old requirements. I think your analysis is correct. 1. What constitutes an "alternative success" indication in the EAP-TLS 1.3 protocol? The -13 commitment message verifies that both sides are in possession of a derived key. But the server finished already does that. As you state, the -13 commitment message is not an alternative success indication. I think it would be easy to make it an alternative success indication be mandating that the EAP-TLS server must only send it after verifying the client finished. I do not think defining a new exporter is needed. The -14 close_notify is also not an alternative success indication and can not be made into one either. If the requirement is that an alternative authenticated success indication is needed. Then I think: - We need to have an extra roundtrip. - close_notify does not work and cannot be made to work - Application data commit message could work as an alternative success indication. TLS would have to be profiled so the alternative success is only send be EAP-TLS server after client finished processed successfully. 2. At what point should keys be pushed do
Re: [TLS] AD Evaluation of draft-ietf-tls-dtls13-39
I have posted -41, which I believe to be ready for IETF LC
-Ekr
On Sun, Feb 7, 2021 at 12:36 PM Eric Rescorla wrote:
>
>
> On Fri, Feb 5, 2021 at 5:16 PM Benjamin Kaduk wrote:
>
>> Hi Ekr,
>>
>> Thanks for all the updates, and sorry to have dropped the ball over the
>> holidays.
>>
>> The changes in the -40 are basically all good, and I filed several PRs to
>> cover a few nits and places where you asked for suggested text. (I see
>> you
>> merged most of them already; thanks!) For everybody not getting
>> notifications for the githb repo, those are:
>>
>> https://github.com/tlswg/dtls13-spec/pull/208 (general nits)
>> https://github.com/tlswg/dtls13-spec/pull/209 (implementation pitfalls)
>> https://github.com/tlswg/dtls13-spec/pull/210 (anti-replay window per
>> epoch)
>> https://github.com/tlswg/dtls13-spec/pull/211 (implicit ACK)
>> https://github.com/tlswg/dtls13-spec/pull/212 (more security
>> considerations)
>>
>
> Thanks. I have merged these.
>
> The only other comment I had on the -40 that I didn't make a PR for is that
>> (now that we have the automation working to generate appendixes for the
>> procotol-description language) we don't actually show the new value for
>> ACK
>> as a ContentType anywhere! It seems like we'd have to stick that in
>> Figure
>> 2 if we put it anywhere, though that's admittedly a bit disjointed from
>> where we actually start talking about the message in question.
>>
>
> Yeah, I think we can take a pass on this, but if someone has a clever
> idea, I'll
> take a PR.
>
> >
>> > > Section 4.5.3
>> > >
>> > > As mentioned above, we might mention any reduced limits due to
>> > > sequence-number protection (e.g., with ChaCha20) here, if they exist.
>> >
>> > Filed an issue:
>> > https://github.com/tlswg/dtls13-spec/issues/167
>>
>> It looks like we were maybe going to add a note saying that we don't know
>> the confidentiality bounds for multiple applications of RNE, but I don't
>> think we necessarily need to hold up for that.
>>
>
> MT and I discussed this and came to the conclusion it was OK because the
> nonce is 128-bits long and the bounds are much lower.
>
> https://github.com/tlswg/dtls13-spec/issues/167
>
>
>> > > (I note that a bit further on we say
>> > > "MUST create a new ClientHello ... [following] Section 4.1.2 of
>> > > [TLS13]", which seems to be enough of a normative requirement that the
>> > > "MUST" may not be needed here.)
>> > >
>> > >The cookie extension is defined in Section 4.2.2 of [TLS13]. When
>> > >
>> > > Do we want to add any discussion of what is stored in the cookie
>> (other
>> > > than the RFC 2522-like address+ports and the ClientHello1 hash that
>> > > [TLS13] mentions), as mentioned in the thread at
>> > >
>> https://mailarchive.ietf.org/arch/msg/tls/QbteFvnk1H2K9OjfHGosuG9e9Rk/ ?
>> > > I am somewhat amenable to the stance that it's more appropriately done
>> > > in 8446bis.
>> >
>> > Yes, I think so.
>> > https://github.com/tlswg/tls13-spec/issues/1206
>>
>> This is still open (on 8446bis), but maybe my
>> https://github.com/tlswg/dtls13-spec/pull/212 covers some of the key
>> points for this document.
>>
>
> I think it does.
>
>
>> > > Section 5.3
>> > >
>> > > [Discussing ServerHello here for want of a better location.]
>> > >
>> > > We specify a ClientHello.legacy_version = {254,253}, but we seem to be
>> > > inheriting the unmodified TLS 1.3 ServerHello, complete with
>> > > ServerHello.legacy_version = 0x0303. That seems problematic, since
>> the
>> > > legacy DTLS 1.2 ServerHello would use the expected {254,253} like the
>> > > ClientHello.
>> >
>> > https://github.com/tlswg/dtls13-spec/issues/170
>> >
>> >
>> > > Similarly, we should probably specify whether the sentinel
>> > > downgrade-protection Random values are used as-is from TLS 1.3, or if
>> we
>> > > have new ones for DTLS.
>> > > [end ServerHello topics]
>> >
>> > I don't think we need new ones. Don't we just inherit it?
>>
>> I think inheriting the same ones should work, protocol-wise.
>> I was only asking about mentioning them specifically sinnce their stated
>> semantics are tied to "if negotiating TLS 1.2" and "if negotiating TLS 1.1
>> or below", and a literal reading of those requirements doesn't make sense
>> for DTLS versions.
>>
>
> https://github.com/tlswg/dtls13-spec/pull/213
>
> > I don't think I understand you. This is a lockstep protocol so if you
>> > are sending the next flight, then the previous flight must have
>> > been received. In the post-handshake, you can run concurrent
>> > state machines.
>>
>> This was just an editorial comment, that the parenthetical "emptying the
>> buffer first" seems pretty vague about what is supposed to happen (and if
>> the buffer that's getting emptied is the same one used for "buffers them
>> for transmission"). My understanding of what's supposed to happen in
>> practice matches my understanding of your description here.
>>
>
> I changed it to "transmission buffer"
>
>>
>> > > The wording here is a bit
[TLS] I-D Action: draft-ietf-tls-dtls13-41.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 Authors : Eric Rescorla Hannes Tschofenig Nagendra Modadugu Filename: draft-ietf-tls-dtls13-41.txt Pages : 68 Date: 2021-02-07 Abstract: This document specifies Version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection/non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tls-dtls13-41.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-41 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] AD Evaluation of draft-ietf-tls-dtls13-39
On Fri, Feb 5, 2021 at 5:16 PM Benjamin Kaduk wrote:
> Hi Ekr,
>
> Thanks for all the updates, and sorry to have dropped the ball over the
> holidays.
>
> The changes in the -40 are basically all good, and I filed several PRs to
> cover a few nits and places where you asked for suggested text. (I see you
> merged most of them already; thanks!) For everybody not getting
> notifications for the githb repo, those are:
>
> https://github.com/tlswg/dtls13-spec/pull/208 (general nits)
> https://github.com/tlswg/dtls13-spec/pull/209 (implementation pitfalls)
> https://github.com/tlswg/dtls13-spec/pull/210 (anti-replay window per
> epoch)
> https://github.com/tlswg/dtls13-spec/pull/211 (implicit ACK)
> https://github.com/tlswg/dtls13-spec/pull/212 (more security
> considerations)
>
Thanks. I have merged these.
The only other comment I had on the -40 that I didn't make a PR for is that
> (now that we have the automation working to generate appendixes for the
> procotol-description language) we don't actually show the new value for ACK
> as a ContentType anywhere! It seems like we'd have to stick that in Figure
> 2 if we put it anywhere, though that's admittedly a bit disjointed from
> where we actually start talking about the message in question.
>
Yeah, I think we can take a pass on this, but if someone has a clever idea,
I'll
take a PR.
>
> > > Section 4.5.3
> > >
> > > As mentioned above, we might mention any reduced limits due to
> > > sequence-number protection (e.g., with ChaCha20) here, if they exist.
> >
> > Filed an issue:
> > https://github.com/tlswg/dtls13-spec/issues/167
>
> It looks like we were maybe going to add a note saying that we don't know
> the confidentiality bounds for multiple applications of RNE, but I don't
> think we necessarily need to hold up for that.
>
MT and I discussed this and came to the conclusion it was OK because the
nonce is 128-bits long and the bounds are much lower.
https://github.com/tlswg/dtls13-spec/issues/167
> > > (I note that a bit further on we say
> > > "MUST create a new ClientHello ... [following] Section 4.1.2 of
> > > [TLS13]", which seems to be enough of a normative requirement that the
> > > "MUST" may not be needed here.)
> > >
> > >The cookie extension is defined in Section 4.2.2 of [TLS13]. When
> > >
> > > Do we want to add any discussion of what is stored in the cookie (other
> > > than the RFC 2522-like address+ports and the ClientHello1 hash that
> > > [TLS13] mentions), as mentioned in the thread at
> > > https://mailarchive.ietf.org/arch/msg/tls/QbteFvnk1H2K9OjfHGosuG9e9Rk/
> ?
> > > I am somewhat amenable to the stance that it's more appropriately done
> > > in 8446bis.
> >
> > Yes, I think so.
> > https://github.com/tlswg/tls13-spec/issues/1206
>
> This is still open (on 8446bis), but maybe my
> https://github.com/tlswg/dtls13-spec/pull/212 covers some of the key
> points for this document.
>
I think it does.
> > > Section 5.3
> > >
> > > [Discussing ServerHello here for want of a better location.]
> > >
> > > We specify a ClientHello.legacy_version = {254,253}, but we seem to be
> > > inheriting the unmodified TLS 1.3 ServerHello, complete with
> > > ServerHello.legacy_version = 0x0303. That seems problematic, since the
> > > legacy DTLS 1.2 ServerHello would use the expected {254,253} like the
> > > ClientHello.
> >
> > https://github.com/tlswg/dtls13-spec/issues/170
> >
> >
> > > Similarly, we should probably specify whether the sentinel
> > > downgrade-protection Random values are used as-is from TLS 1.3, or if
> we
> > > have new ones for DTLS.
> > > [end ServerHello topics]
> >
> > I don't think we need new ones. Don't we just inherit it?
>
> I think inheriting the same ones should work, protocol-wise.
> I was only asking about mentioning them specifically sinnce their stated
> semantics are tied to "if negotiating TLS 1.2" and "if negotiating TLS 1.1
> or below", and a literal reading of those requirements doesn't make sense
> for DTLS versions.
>
https://github.com/tlswg/dtls13-spec/pull/213
> I don't think I understand you. This is a lockstep protocol so if you
> > are sending the next flight, then the previous flight must have
> > been received. In the post-handshake, you can run concurrent
> > state machines.
>
> This was just an editorial comment, that the parenthetical "emptying the
> buffer first" seems pretty vague about what is supposed to happen (and if
> the buffer that's getting emptied is the same one used for "buffers them
> for transmission"). My understanding of what's supposed to happen in
> practice matches my understanding of your description here.
>
I changed it to "transmission buffer"
>
> > > The wording here is a bit amusing, as "up to no less than the ...
> > > maximum" is facially nonsensical, but the RFC 6298 setting is in fact
> > > the floor for the implementation-defined maximum. I don't have a
> clever
> > > wording suggestion, though.
> >
> > Hmm I don't think it's nonsensical, be
[TLS] RFC 3546 (Transport Layer Security Extensions) - 3.1 Server Name Indication
Hello! I have a question regarding a paragraph in the definition of SNI in RFC 3546. Citing: > Literal IPv4 and IPv6 addresses are not permitted in "HostName". As far as I understand, the HostName field is used by the (web) server when deciding what certificate to send based on the ClientHello. Let's say, for backwards compatibility with older clients that do not support SNI, that the server will always respond with domain.example TLS certificate when SNI is not present. The server, however, also has a specific certificate for use when the client connects directly to the IP address (in case of HTTPS that would for example be a request for https://192.0.2.1/). Using the current specifications and configurations there is no way for a client to get the correct certificate for 192.0.2.1, because it can't signal to the server that it's connecting directly to an IP address. This sounds like a limitation to me. Is there any way for a server to differentiate between a client that does not support SNI and connects to domain.example and a client that supports SNI but connects to 192.0.2.1? What issues would be created if the above-mentioned paragraph was removed and the definition of HostName would be changed to allow FQDNs AND IP addresses? What is the reasoning behind limiting HostName field only to FQDNs? If allowing HostName would break something, would it be possible to add another NameType, IPAddress, that would support signaling IP addresses to the server? A similar issue was already discussed in quic-issues@ietf on 2020-01-07. Thanks! -- Anton Luka Šijanec ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
