Subject: Does rfc2222bis need text on channel bindings?

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Aug 2004 19:47:13 -0500

I figure the new SASL GSS mech document will say something about channel
bindings, but perhaps rfc2222bis should also.

Specifically I think that rfc2222bis could use:

a) Security Considerations text about use of mechanisms that don't
   support channel bindings in conjunction with TLS.

   Clients should be admonished to validate TLS server IDs to prevent
   MITM attacks when using SASL-over-TLS.  Similarly with other variants
   of SASL-over-TLS.

   SACRED is an example of an application where such text could be
   useful.

b) Text recommending support for channel bindings in future mechanisms,
   where possible.  Digest-MD5, for example, could easily support
   channel bindings.

Comments?  Shall I just send proposed text to the list?

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 Aug 2004 16:52:46 +0100

>   MITM attacks when using SASL-over-TLS.  Similarly with other variants
I suspect you mean "SASL-over-<foo>".

>   where possible.  Digest-MD5, for example, could easily support
If you mean that it can be easily extended, then I agree.

>Comments?  Shall I just send proposed text to the list?
Please do.

Alexey

---

From: Sam Hartman <[email-masked]>
Date: Fri, 13 Aug 2004 13:14:25 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> I figure the new SASL GSS mech document will say
    Nicolas> something about channel bindings, but perhaps rfc2222bis
    Nicolas> should also.

I do hope the new GSSAPI draft discusses this issue.

    Nicolas> Specifically I think that rfc2222bis could use:

    Nicolas> a) Security Considerations text about use of mechanisms
    Nicolas> that don't support channel bindings in conjunction with
    Nicolas> TLS.

This seems problematic given that all current mechanisms don't support
channel bindings.

I think the best we could do is security considerations text
describing the multiple layers problem.

    Nicolas>    Clients should be admonished to validate TLS server
    Nicolas> IDs to prevent MITM attacks when using SASL-over-TLS.
    Nicolas> Similarly with other variants of SASL-over-TLS.

Agreed.

    Nicolas> b) Text recommending support for channel bindings in
    Nicolas> future mechanisms, where possible.  Digest-MD5, for
    Nicolas> example, could easily support channel bindings.

This sounds out of scope for the SASL working group.  I believe our
charter prohibits us from adding new features to SASL.  I don't think
it has similar prohibitions for the GSSAPI mechanism.

I agree channel bindings are a good thing for SASL.  I disagree that
they are well specified enough for us to be adding text about them to
the base sasl document for this revision.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 13 Aug 2004 16:52:46 +0100

Please do.

Alexey

---

From: Sam Hartman <[email-masked]>
Date: Fri, 13 Aug 2004 13:14:25 -0400

Agreed.