Subject: rfc2222bis: suggested text about multiple SASL mechanisms

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 9 Nov 2003 20:31:56 +0100

I suggest this text is added to rfc2222bis, probably in the Security
Considerations.  I stole it from draft-ietf-ldapbis-authmeth-08.txt and
de-LDAPified it.

   If the client fetches a list of supported SASL mechanisms from the
   server and bases its choice of SASL mechanism on the result, it
   SHOULD fetch that list both before and after the SASL security layer
   is negotiated.  This allows the client to detect active attacks that
   remove mechanisms from the server's list of supported mechanisms, and
   allows the client to ensure that it is using the best mechanism
   supported by both client and server.

-- 
Hallvard

---

From: Rob Siemborski <[email-masked]>
Date: Sun, 9 Nov 2003 16:33:41 -0500 (EST)

>    supported by both client and server.

Isn't this attack defeated simply by requiring the clients to not pick a
mechanism that does not meet their minimum requirements for
authentication?

There are also currently deployed servers that do not continue to
advertise their sasl mechanisms after authentication, since in almost
all current protocols it is not valid to issue a second sasl
authentication command.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----

---

From: Sam Hartman <[email-masked]>
Date: Sun, 09 Nov 2003 18:44:13 -0500

>>>>> "Rob" == Rob Siemborski <[email-masked]> writes:

    Rob> On Sun, 9 Nov 2003, Hallvard B Furuseth wrote:

    >> If the client fetches a list of supported SASL mechanisms from
    >> the server and bases its choice of SASL mechanism on the
    >> result, it SHOULD fetch that list both before and after the
    >> SASL security layer is negotiated.  This allows the client to
    >> detect active attacks that remove mechanisms from the server's
    >> list of supported mechanisms, and allows the client to ensure
    >> that it is using the best mechanism supported by both client
    >> and server.

    Rob> Isn't this attack defeated simply by requiring the clients to
    Rob> not pick a mechanism that does not meet their minimum
    Rob> requirements for authentication?

No, I wouldn't call that defeated.  You get better protection by
checking after the fact.

    Rob> There are also currently deployed servers that do not
    Rob> continue to advertise their sasl mechanisms after
    Rob> authentication, since in almost all current protocols it is
    Rob> not valid to issue a second sasl authentication command.

That's why he said SHOULD not MUST;)

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 10 Nov 2003 07:26:39 +0100

> That's why he said SHOULD not MUST;)

Well, it would have been if I had thought of it...
I guess I should have put an 'if possible' in there somewhere.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 12 Nov 2003 16:17:15 +0100

Rob Siemborski writes:
> I'd be much happier either not adding this, or adding it as a "clients MAY
> want to do this to detect MITM attacks"

Fine by me.  I don't feel strongly about it, I just saw it in LDAP and
thought it might be a good idea.

-- 
Hallvard

---

From: Rob Siemborski <[email-masked]>
Date: Wed, 12 Nov 2003 10:02:13 -0500 (EST)

> No, I wouldn't call that defeated.  You get better protection by

I know we briefly discussed this in the meeting yesterday and we left
it as "probably ok, with some modifications to the text"...

I think for me to be happy with the addition of the text, it would need to
both have the "if possible" fix, and a clarification that if a server
advertises NO mechanisms after authentication, or the protocol does not
support fetching capabilities after authentication -- as is the case with
MUPDATE (though granted, it isn't standards track), then it MUST NOT act
as if a MITM attack was detected.

But I'm still unclear why this is necessary when:

a) it most likely adds an extra round trip to the authentication process
b) it may not even work with all protocols/implementations -- so that
   round trip will be wasted

What are we trying to prevent here, exactly?  The scenario where it
applies seems to be something along the lines of:

The server advertises GSSAPI and DIGEST-MD5.

The client, for whatever reason, decides only GSSAPI (with privacy layer)
is secure enough for it.

The attacker edits the advertised capabilites and removes GSSAPI, the
client sees that the server only supports DIGEST-MD5.  I argue that the
client should fail the authentication here and not even try to
authenticate -- the MITM attack has been defeated.  If instead it
authenticates, then that implies that it is okay with using DIGEST-MD5.
Even if it later discovers that GSSAPI was available, it should be ok with
using DIGEST for the session -- what is it going to tell the user "uh, I
sent your credentials with a mechanism you didn't want to use, and guess
what -- there's an attack in progress!".

Sure, the protection may be "better" (as in, you can detect that an attack
is in progress), but the costs are high (additional round trip, it might
not work anyway) for what seems to me to be a very small gain.

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Sam Hartman <[email-masked]>
Date: Fri, 14 Nov 2003 22:16:15 -0500

>>  No, I wouldn't call that defeated.  You get better protection
    >> by checking after the fact.

    Rob> I know we briefly discussed this in the meeting yesterday and
    Rob> we left it as "probably ok, with some modifications to the
    Rob> text"...

    Rob> I think for me to be happy with the addition of the text, it
    Rob> would need to both have the "if possible" fix, and a
    Rob> clarification that if a server advertises NO mechanisms after
    Rob> authentication, or the protocol does not support fetching
    Rob> capabilities after authentication -- as is the case with
    Rob> MUPDATE (though granted, it isn't standards track), then it
    Rob> MUST NOT act as if a MITM attack was detected.

One thing we need to keep in mind is that over time, we get a better
idea of what best practices for using SASL are.  Some of our older
protocols may not support these best practices.   I'd rather encourage
new protocols to implement the best practices.  So, rather than saying
that if the server  returns no mechanisms the client should not treat
it as  a MITM attack, I'd like to say something like the following.

New protocol profiles SHOULd require servers to make the list of SASL
mechanisms available for the initial authentication available to the
client after security layers are established.  Some older protocols do
not require this; for these protocols clients MUST NOT treat  an empty
list of SASL mechanisms after authentication as a MITM attack.

    Rob> But I'm still unclear why this is necessary when:

    Rob> a) it most likely adds an extra round trip to the
    Rob> authentication process b) it may not even work with all
    Rob> protocols/implementations -- so that round trip will be
    Rob> wasted

    Rob> What are we trying to prevent here, exactly?  The scenario
    Rob> where it applies seems to be something along the lines of:

This is valuable because people tend to have fairly lax security
configurations on their clients and servers in the interest of
interoperability.  If there are things we can do to make an attacker's
life harder--like protecting negotiations--then we should do so unless
doing so has sufficiently negative consequences.

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 14 Nov 2003 23:31:35 -0500 (EST)

> list of SASL mechanisms after authentication as a MITM attack.

This sort of warning seems better to me.

> doing so has sufficiently negative consequences.

I'm not really convinced there are truly strong benefits here, but since
it will mostly be a recommendation for new protocols (which can be
designed to negate any negative costs such as the extra round trip), I
won't oppose it either (given text along the lines of what you suggest
above).

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Rob Siemborski <[email-masked]>
Date: Sun, 9 Nov 2003 16:33:41 -0500 (EST)

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Sam Hartman <[email-masked]>
Date: Sun, 09 Nov 2003 18:44:13 -0500

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 10 Nov 2003 07:26:39 +0100

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 12 Nov 2003 16:17:15 +0100

-- 
Hallvard

---

From: Rob Siemborski <[email-masked]>
Date: Wed, 12 Nov 2003 10:02:13 -0500 (EST)

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Sam Hartman <[email-masked]>
Date: Fri, 14 Nov 2003 22:16:15 -0500

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 14 Nov 2003 23:31:35 -0500 (EST)

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----