Subject: EXTERNAL security considerations

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 15 Apr 2001 20:50:16 -0700

It seems to me that there some security considerations
which should be noted regarding the EXTERNAL mechanism.

First, I think:
   The server uses information, external to SASL, ...

is a bit too value.  I suggest:
   The server uses authenticated information, external to SASL,

That is, the information used must be verified though
some external authentication process.  The information
should not be easily spoofed, such as the client's
IP address, the DNS name found by reverse lookup, or
information obtained from services operating at this
IP address (such as an RFC1413) authentication service.

I actually suggest EXTERNAL be limited provided by other
means established by the application protocol profile.

Without this, then it would be necessary to state additional
considerations in regards to the client's use of EXTERNAL.
In particular, the client cannot assume the source of
information used by server.

Comments?

Kurt

---

From: John Gardiner Myers <[email-masked]>
Date: Tue, 17 Apr 2001 18:27:10 -0700

> IP address (such as an RFC1413) authentication service.

Even easily spoofed information can qualify as "authentication
information".  Several merchants use things such as taxpayer ID numbers,
phone numbers, and billing addresses as authentication information.

You seem to be trying to impose some sort of minimum strength
requirement for the information to be used by EXTERNAL.  What is the
rationale for such a requirement?

If a site believes that IP-based authentication in a particular
situation conforms to their security policy, EXTERNAL would be the
obvious SASL mechanism to use.  Why should the SASL specification
prohibit this?  If SASL does prohibit this, would that have any chance
of affecting the behavior of the site? 

> means established by the application protocol profile.

I can't parse the sentence.  The mechanism should be independent of the
protocol profile, this is a fundamental tenet of SASL.  IPsec, for
example, is unlikely to be mentioned in any protocol profile.

> information used by server.

Why would additional considerations be needed?  What are the problems?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 17 Apr 2001 19:02:29 -0700

>rationale for such a requirement?

I want to:
        a) REQUIRE authentication (verification of information to
          establish identity claimed),
        b) RECOMMEND easily spoofed information not be used.

The rational is that EXTERNAL is an authentication mechanism
and we should recommend reasonable secure uses of that mechanisms.
That does not mean that it cannot be implemented or used contrary to
these requirements.

>of affecting the behavior of the site? 

My intent was not to prohibit this, but to recommend against
such uses.  As we design for the Internet, such recommendat

>protocol profile, this is a fundamental tenet of SASL.

Well, I note that many issues are left to profiles.  Including
which mechanisms to mandate and/or recommended, how to manage
authentication and authorization identities, etc.  The tenet
is not pure.

>IPsec, for

I'm concerned that a box-in-the-middle could get a client to
use EXTERNAL to believe it has authenticated to the intended
server when it hasn't.  This could lead to the client then
attempting operations which would be exposed to the
box-in-the-middle.  The bottom line is that the client needs
to be very careful of its use of EXTERNAL.

---

From: John Gardiner Myers <[email-masked]>
Date: Wed, 18 Apr 2001 16:00:51 -0700

> to be very careful of its use of EXTERNAL.

This problem is not specific to EXTERNAL--it also applies to CRAM-MD5
and any other mechanism which does not support mutual authentication. 
This is the attack that mutual authentication is designed to defend
against.

This all boils down to the fact that implementations need to determine
the security policy and then enforce it.  Clients that need to protect
against such attacks need to have a security policy that requires mutual
authentication.  As with integrity and confidentiality protection,
enforcing the security policy means prohibiting the use of mechanisms
which do not provide the required protections unless those protections
are provided by some service external to SASL.

For additional security considerations, the only thing I can think of
doing is to try to list a taxonomy of security features that
implementations may want to consider when choosing mechanisms.  Such a
list could never be exhaustive and I don't think it belongs in this
document.  The only other thing we could state is that EXTERNAL does not
itself provide any security protection; this point is obvious.

>           establish identity claimed),

We perhaps have different definitions of "authentication."  To me,
authentication is using information to associate a non empty set of
identities (usually with one primary identity) with a communication
peer.  Authentication by assertion (peer sends a message claiming peer
has identity X), while extremely weak, is still authentication.  The
ANONYMOUS mechanism uses this.

Once you bring in the word "verification," you are in the realm of
threat models and risk analysis.  You can't just talk about
verification, you have to talk about resistance to particular types of
attacks.

The IETF has identified particular types of attacks as being of special
concern: eavesdropping and replay.  All protocols must adequately
protect against such attacks.  man-in-the-middle attacks are not in this
set.

> The rational[e] is that EXTERNAL is an authentication mechanism

We currently recommend use of EXTERNAL with TLS and IPsec, which are
reasonably secure.

We could put a statement similar to the requirement in RFC 2595 section
6 that implementations MUST NOT use PLAIN unless a strong encryption
layer is active or the implementation really wants to.  Such a statement
would be more likely to call attention to the possibility than to
discourage its use.

> authentication and authorization identities, etc.  The tenet

These issues are entirely in the profile/implementation's area.  The
requirement for protocols to select and mandate particular mechanisms is
an IETF-wide policy.  The mechanisms themselves need not know about such
mandates.  They only need to know the security policy, which can be
given to them in a mechanism independent form.

Similarly, mechanisms only need to provide the authentication and
authorization identities.  It is up to the profile/implementation to
provide policy and interpretation.  In the SASL library APIs I've seen,
this separates well: the server provides the mechanism code with
callbacks for canonicalizing authenticaiton and authorization ids and
for applying the site's proxy authentication/access policy.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 18 Apr 2001 18:26:29 -0700

If EXTERNAL were detailed in another document, that document
would have a section detailing security considerations
related to the specification, implementation, and use of the
mechanism.  Like ANONYMOUS and PLAIN, there are quite a number
of significant considerations to note (as you yourself have
noted in this thread).  In some cases, they may be quite
obvious to you and I, but we should not assume they are obvious
to all.

>layer is active or the implementation really wants to.

Such would address my primary concern.

Kurt

---

From: John Gardiner Myers <[email-masked]>
Date: Tue, 24 Apr 2001 16:33:38 -0700

"Kurt D. Zeilenga" wrote:
> mechanism.

Such a section would simply note "The EXTERNAL mechanism provides no
security protection; it is vulnerable to spoofing by either client or
server, active attack, and eavesdropping.  It should only be used when
such external security mechanisms are present and have sufficient
strength."  The section would then refer to the security considerations
section of the base SASL spec.

I will add the quoted text to base SASL spec.

Security considerations are best when they are in the form recommended
by section 9 of RFC 2316.  Each consideration should clearly state the
set of threats it addresses.

---

From: John Gardiner Myers <[email-masked]>
Date: Tue, 17 Apr 2001 18:27:10 -0700

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 17 Apr 2001 19:02:29 -0700

I want to:

---

From: John Gardiner Myers <[email-masked]>
Date: Wed, 18 Apr 2001 16:00:51 -0700

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 18 Apr 2001 18:26:29 -0700

Kurt

---

From: John Gardiner Myers <[email-masked]>
Date: Tue, 24 Apr 2001 16:33:38 -0700