XEP-0440: Rework Security Considerations and related sections #1477
Conversation
tmolitor-stud-tu
force-pushed
the
0440-update-01
branch
3 times, most recently
from
9d94061 to
cbd560d
Compare
|
I've cleaned it up a bit and removed unnecessary SCRAM references. The new rendered version: |
tmolitor-stud-tu
force-pushed
the
0440-update-01
branch
2 times, most recently
from
14fc837 to
dd52abe
Compare
|
@Flowdalic Daniel commented, that "(or just randomly pick a channel-binding and hope for the best)" sounds weirdly untechnical, so I force pushed a small change here. |
There was a problem hiding this comment.
LGTM. But please use "SASL mechanisms with channel-binding support" instead of "*-PLUS".
I would have also welcomed not mixing trivial fixes within the same commit as the big rewording change. And some rationale for the rewording in the commit message.
Besides that, please feel free to add yourself as author of the document, if you want to.
xep-0440.xml
Outdated
| Clients SHOULD implement tls-server-end-point and use it if no other | ||
| (stronger) channel-binding method is supported by both sides.</li> | ||
| <li>If the client doesn't support channel-binding, it MUST send "n" in the GSS-header (see &rfc5802;).</li> | ||
| <li>If the client supports channel-binding, but the server announced neither '*-PLUS' nor |
There was a problem hiding this comment.
This implies that only SASL mechanisms ending with -PLUS support channel-binding. This may be true now, but may not hold in the future.
| <li>If the client supports channel-binding, but the server announced neither '*-PLUS' nor | |
| <li>If the client supports channel-binding, but the server announced no SASL mechanisms supporting channel binding nor |
xep-0440.xml
Outdated
| <li>If the client supports channel-binding, but the server announced neither '*-PLUS' nor | ||
| channel-binding types (via this specification), it MUST send "y" in accordance to &rfc5802;.</li> | ||
| <li>If the client is using SASL2 (&xep0388;) to authenticate and received announcements | ||
| for '*-PLUS' from the server, but no channel-binding types, it MUST abort the authentication |
xep-0440.xml
Outdated
| This condition is undefined with SASL1 (&rfc6120;), but the client MAY also abort authentication | ||
| in this case (or just randomly pick a channel-binding and hope for the best).</li> | ||
| <li>If the client is using SASL2 to authenticate and it receives channel-binding announcements, | ||
| from the server, but no '*-PLUS' methods are announced, it MUST abort authentication |
xep-0440.xml
Outdated
| from the server, but no '*-PLUS' methods are announced, it MUST abort authentication | ||
| (this is an implementation error or ongoing MITM attack). It SHOULD do the same when using SASL1.</li> | ||
| <li>If the client is using either SASL1 or SASL2 to authenticate and receives announcements for | ||
| '*-PLUS' methods and channel-binding types, but none of these announced channel-binding types are |
xep-0440.xml
Outdated
| in this case (or just randomly pick a channel-binding and hope for the best).</li> | ||
| <li>If the client is using SASL2 to authenticate and it receives channel-binding announcements, | ||
| from the server, but no '*-PLUS' methods are announced, it MUST abort authentication | ||
| (this is an implementation error or ongoing MITM attack). It SHOULD do the same when using SASL1.</li> |
There was a problem hiding this comment.
| (this is an implementation error or ongoing MITM attack). It SHOULD do the same when using SASL1.</li> | |
| (this is an implementation error or ongoing MITM attack where SASL mechanisms are stripped). It SHOULD do the same when using SASL1.</li> |
| </ol> | ||
|
|
||
| <p>The RFC explains, that sending "y" when the server advertised channel-binding | ||
| support is to be used as a MITM-detection. An attacker stripping out all *-PLUS variants can be detected this way: |
There was a problem hiding this comment.
No, this talks exclusively about SCRAM, so *-PLUS is fine here.
| <p>A client following the rules above and seeing a server-advertised list without | ||
| tls-sever-end-point, immediately knows, that some attacker tampered with the list of channel-binding types | ||
| and can abort the authentication. It never needs to send "n" even though it supports channel-binding and | ||
| can still safely send "y" if it doesn't see any '*-PLUS' variants and channel-bindings announced.</p> |
There was a problem hiding this comment.
No, this talks exclusively about SCRAM, so *-PLUS is fine here.
|
Good point regarding the -PLUS stuff! |
|
@tmolitor-stud-tu: Thanks for your work on the XEP-0440. But why have you removed the RFC 5056 part? The "RFC 5056: On the Use of Channel Bindings to Secure Channel" is not obsolete: cc: @nicowilliams (Nicolas Williams, author of RFC 5056, RFC 5801, RFC 5802, RFC 5929 and a lot others). |
|
@Neustradamus Please don't spam and try to understand the file format before posting! |
|
|
Ah, upon revisiting the -PLUS stuff, I'm not sure anymore, if using "SASL mechanisms supporting channel-bindin" instead of We could add some pointer that the |
|
Okay, I removed the |
tmolitor-stud-tu
force-pushed
the
0440-update-01
branch
from
dd52abe to
535706e
Compare
This update addresses a possible MITM attack vector by making the tls-server-end-point channel-binding mandatory to implement. This significantly raises the bar for such MITM attackers. The new Business Rules section explains the details how to remedy the attack vector, while the Security Considerations section gives a detailed explanation for these rules.
This also adds a new SASL2 example alongside the SASL1 one.
tmolitor-stud-tu
force-pushed
the
0440-update-01
branch
from
535706e to
32d34d6
Compare
|
Okay, I've split also the commit now :) |
3 participants
This is my proposed PR resulting from the discussions at standards@.
The rendered HTML.
@Flowdalic feel free to call me out on anything you don't like and I'll be happy to change it :)