Subject: Replacing a SASL security layer

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Oct 2003 23:16:54 +0100

>>>   Below the term "realm" has the meaning as defined in the section 5.
>>>   A security layer that remains in effect when a client, which already
>>>   has authenticated and established the security layer with "Realm A",
>>>   authenticates to "Realm B", without negotiating a new security layer,
>>>   enables "Realm B" to make guesses about previously observed
>>>   ciphertext using the server's SASL engine as an oracle. "Realm B" may
>>>   observe how known cleartext is encrypted.
>>>
>>>              +---------+                   +---------+
>>>              |         |                   |         |
>>>              | Realm B |                   | Realm A |
>>>              |         |                   |         |
>>>              +---------+                   +---------+
>>>                  |  ^                           |
>>>                  |  :      +-----------+        |
>>>     Traffic from |  :      | Encryption|        | Traffic from A
>>>      B to client +-------->| end point |<-------+ to client
>>>                     :      | (SSL/SASL)|
>>>                     :      +-----------+
>>>                     :            |
>>>                     :            |
>>>                     :          +---+
>>>                     :          |   |
>>>                     :          |   |
>>>                     :          |   | Encryption tunnel, e.g. SASL or 
>>> SSL,
>>>                     :          |   | between the server
>>
>>>           encrypted            |   | Separate tunnels to different
>>>           traffic between      |   | clients.
>>>           Realm A and client   +---+
>>>                                  |
>>>                                  |
>>>                                  +-----------> Traffic to clients
>>
>
> This discussion is confusing and makes no sense to me.  SASL doesn't 
> protect traffic between "realms" and clients; it protects traffic 
> between _servers_ and clients.  This needs to be reworded so it makes 
> sense, in terms of entities known to the SASL framework.  A "realm" is 
> not such an entity; it is no more than part of the autentication 
> identities used by some mechanisms, and has no place outside the 
> mechainsm specification.
>
> Put another way, and ignoring the issue of "realms"; the above 
> description makes so little sense to me that I cannot evaluate its 
> validity or understand what attack we are trying to avoid. 

Ignore for a moment any relationship of realm to DIGEST-MD5, GSSAPI or 
any other SASL mechanism. Let's use the definition I have in the document:

Conceptually, realm is the name of a collection of user's accounts.
Realms allow the protected resources on a server to be partitioned into
a set of protection spaces, each with its own authentication mechanisms
and/or authorization database. For example, a proxy/frontend can use
different realms for different servers/backends it represents.

So, each "realm" ("a protection space") is served by a separate server 
(proxy example above) or a separate process/plugin (frontend-backend 
example). Does it make more sense now?

Alexey

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 09 Oct 2003 19:52:29 -0700

A concern here is that a number of application profiles
specify (and developers have implemented) SASL layers such
that established layers cannot be deinstalled except to install
new layers.  Changing this now will naturally introduce some
interoperability, so we need to be sure that the change is well
justified.  I wonder if it might be better to not to change the
protocol but, instead, just document the security consideration.

Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 10 Oct 2003 10:45:37 +0100

Kurt D. Zeilenga wrote:

>new layers.
I am only aware of one protocol that might do that: LDAP.

>  Changing this now will naturally introduce some
>justified.
I don't believe anybody implements this right anyway (please, do let me 
know if I am right).

>  I wonder if it might be better to not to change the
I would like to allow new protocols to allow to deinstall the security 
layer when none is negotiated. RFC 2222 prohibits this.
IMHO, it is fine if an existing protocol doesn't do that (and documents 
the issue in Security considerations), but there is no point of forcing 
brokeness on new protocols.

Cheers,
Alexey
__________________________________________
Isode Limited, http://www.isode.com

Cell: +44 7753759732

IETF standard related pages:
http://orthanc.ab.ca/mel/devel/Links.html

Personal Home Page: http://orthanc.ab.ca/mel
__________________________________________

---

From: Sam Hartman <[email-masked]>
Date: Mon, 27 Oct 2003 16:17:27 -0500

>>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:

    >> I wonder if it might be better to not to change the protocol
    >> but, instead, just document the security consideration.
    >> 
    Alexey> I would like to allow new protocols to allow to deinstall
    Alexey> the security layer when none is negotiated. RFC 2222
    Alexey> prohibits this.  

Why do you want this?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 09 Oct 2003 19:52:29 -0700

Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 10 Oct 2003 10:45:37 +0100

Cheers,
Alexey

Cell: +44 7753759732

---

From: Sam Hartman <[email-masked]>
Date: Mon, 27 Oct 2003 16:17:27 -0500

Why do you want this?