Subject: sasl-rfc2222bis: multiple authentication attack

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 25 Feb 2004 15:08:30 -0800

In review of the latest draft, I've come across a number of
technical and editorial concerns which I intend to start a number
of separate threads on.  This is the first.

I am particularity perplexed by the long discussion of the
"Multiple Authentication attack", an attack which only
impacts certain kinds of distributed server implementations,
which seems to overshadow higher risk, more generally
applicable attacks.  I am quite concerned about the
addition of:
>   The protocol profiles that allow for
>   reauthentication SHOULD recommend that another security layer is
>   negotiated once a security layer was installed.

as, if the implementation were subject to this kind of attack,
simply recommending, or even requiring, negotiation of another
security layer does not fully mitigate the risk.  A server which
is subject to such attack should simply refuse re-authentication
(or if the implementor was only concerned about post re-authentication
attacks, it can refuse re-authentications which don't result in
installation of new layers).  It seems odd to address what
is a protocol-neutral security consideration in this fashion (a recommendation upon protocol profiles).

Anyways, as previously discussed (and, I believe, agreed), this issue
is best addressed through statement of security considerations.
Hence, I suggest that all mention of this attack be removed from
section 6.3, including all of section 6.3.1, and that the Security
Consideration mention of 6.3.1 be replaced with (and merged with
the preceding paragraph about distributed server implementations):
    It may be appropriate for a server to disallow all     
    re-authentication, or re-authentications which do not result
    in new security layers being established, involving non-
    (or insufficiently) trusted parties.  In some cases, it may
    be appropriate for the server to require separate connections
    to access information in different protected information spaces.

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Thu, 26 Feb 2004 14:07:03 -0500

>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:

    Kurt> In review of the latest draft, I've come across a number of
    Kurt> technical and editorial concerns which I intend to start a
    Kurt> number of separate threads on.  This is the first.

    Kurt> I am particularity perplexed by the long discussion of the
    Kurt> "Multiple Authentication attack", an attack which only
    Kurt> impacts certain kinds of distributed server implementations,
    Kurt> which seems to overshadow higher risk, more generally
    Kurt> applicable attacks.  I am quite concerned about the addition
    Kurt> of:
    >> The protocol profiles that allow for reauthentication SHOULD
    >> recommend that another security layer is negotiated once a
    >> security layer was installed.

I actually think this text may be reasonable, but would need to think
about it more.

I think the assumption is that by setting up a new security layer you
will end up getting new key material and thus will prevent the new
server from decrypting data destined for the old server.

--Sam

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 26 Feb 2004 12:08:15 -0800

>I actually think this text may be reasonable, but would need to think

Maybe we should have a hallway discussion at IETF#59 before
our session.  Sunday afternoon is good for me.

>server from decrypting data destined for the old server.

I don't disagree that negotiating new layers mitigated, to
some degree, this attack.  (I note however that this alone
does not fully mitigate this class of attack.)  But note that
the text doesn't state a recommendation to negotiate new layers,
it a statement that documents detailing a protocol's use of
SASL SHOULD state a recommendation. 

My suggestion is to, in the security consideration section of
this document, to discuss a class of similar attacks upon a
class of server implementations, and then to suggest approaches
which may be used in these implementations to mitigated these
attacks.

I, however, remain opposed to addition any implementation
or specification imperative that would require/recommend
all server implementations (of all protocols, or select
protocol), including those which are not prone to this
attack, to have to negotiate new security layers.

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Thu, 26 Feb 2004 15:18:26 -0500

>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:

    Kurt> My suggestion is to, in the security consideration section
    Kurt> of this document, to discuss a class of similar attacks upon
    Kurt> a class of server implementations, and then to suggest
    Kurt> approaches which may be used in these implementations to
    Kurt> mitigated these attacks.

Sounds reasonable to me.

    Kurt> I, however, remain opposed to addition any implementation or
    Kurt> specification imperative that would require/recommend all
    Kurt> server implementations (of all protocols, or select
    Kurt> protocol), including those which are not prone to this
    Kurt> attack, to have to negotiate new security layers.

Also reasonable.

So apparently we don't disagree after all.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 26 Feb 2004 13:17:28 -0800

>So apparently we don't disagree after all. 

Apparently.  From this discussion, as well as other recent
discussions, it seems that there might be some disagreement
as to the meaning of the word "profile".

I tend to use the term "protocol profile" to either refer to,
in the SASL context, as:
   The set of items that an specification detailing a
   protocol use of SASL must provide.
or:
   A protocol specification which provides these items.

The following would be a use of the former:
   RFC 2222 provides a profile (e.g., an outline) of
   what an protocol specifications making use of SASL are to
   contain.

and for the latter:
   RFC 2829 provides a profile of how SASL is used in LDAP.

(that latter is, it seems, not perfect).

I, however, try to avoid the term "profile implementation"
as it's ambiguous as to whether it is are referring to the
specification, such as RFC 2829, which provides the profile
or an implementation of that specification.

Of course, as we also are providing in this I-D a requirements
for documents specifying mechanisms, the term becomes even
more overloaded...

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Thu, 26 Feb 2004 14:07:03 -0500

--Sam

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 26 Feb 2004 12:08:15 -0800

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Thu, 26 Feb 2004 15:18:26 -0500

Sounds reasonable to me.

Also reasonable.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 26 Feb 2004 13:17:28 -0800

and for the latter:

Kurt