Re: [saag] is one or two ports "more secure"

[=JeffH <[e-mail]>]

Overall, in summary, I remain in the single-port camp.

FWIW, we IETF have been struggling with this topic since at least 1996/1997 
when the original LDAP/SMTP/IMAP/POP STARTTLS work began, and there's 
detailed discussions in the various archives (where they still exist).

E.g., we (RLBob and I) made arguments for this (single-port per app 
protocol, and policy signaling) back in the early "STARTTLS" days [1][2] on 
[e-mail].

Also, it was discussed on [e-mail], eg..

   Serious design flaw in STARTLS documents
   http://www.imc.org/ietf-apps-tls/mail-archive/msg00155.html

   Man In The Middle Attacks and STARTTLS
   http://www.imc.org/ietf-apps-tls/mail-archive/msg00259.html

   (..there's likely yet more..)

MITM and downgrade attacks are a threat whether one is using a {secure, 
nonsecure} port pair or a single port, so I don't buy that argument as a 
major reason to disfavor a single port approach.

As has been noted in this thread here on this list, a non-trivial aspect of 
the problem is signaling security policy. That's discussed some in [3] (it 
leverages Chris Newman's work) though unfortunately (in some ways) the 
proposal didn't get traction.

=JeffH


[1] [unfortunately, AFAICT, there are no online archives of the 
[e-mail] list, so here's copies-by-value..]

Subject: LDAP URLs and security
From: Jeff Hodges <[e-mail]>
Date: Tue, 06 May 1997 14:38:12 -0700
To: [e-mail]
Cc: [e-mail], [e-mail]

[ The following is a proposal about handling of security in LDAP URLs
that is clearly applicable to all URL schemes, not just LDAP.  We will
be promoting it as such in the appropriate venues.  There is also a
separate rant to follow about how this relates to LDAP over TLS.
  - RL "Bob" and Jeff ]

Here are some comments on the LDAP URL spec, related to URLs and
security.

In the "Security Considerations" section it says:

   The LDAP URL format does not provide a way to specify credentials to use
   when  resolving  the  URL.  Therefore, it is expected that such requests
   will be unauthenticated, unless some out-of-band mechanism is used.

We think the spec can, and must, do better than this.  The assumption
that accesses based on URLs are unauthenticated fails to meet obvious
requirements, and in fact doesn't consider the capabilities of TLS as
embedded in the ldaps: scheme.  It also doesn't meet the security
expectations for new IETF protocols.

The current spec is consistent with the practice with other URL
schemes, which assume that URLs by default are used in a
no-authentication, no-security environment.  We think it is time to
change this practice, and to assume instead that clients interpreting
URLs should attempt to use the security services that are available to
them, falling back to "anonymous" only if there is nothing better.
This allows all URLs to provide views into content that are
appropriate for the authorization level of the requesting client.

IOHO the current practice with URLs has come from their original design
assumptions:

(1)  they were primarily for use with HTTP, a profoundly security-impaired
protocol, and with other protocols that provided only username/password
authentication;

(2)  a "world-wide" perspective, where the likelihood that a client
will have an authentication relationship with a server is minimal;

(3)  a "billboard" perspective, where URLs are handled directly by
users who find them in public sources like web pages and TV
commercials.

All of these assumptions are no longer valid as the use of URLs
expands to new protocols and new uses.

(1)  more and more protocols, including LDAP, have strong security
mechanisms built in, mechanisms that we strongly encourage users to
use instead of username/password;

(2)  the growth of public-key-based security systems implies that a
user may be able to have a useful security association with a server
it has never contacted before; moreover, protocols like LDAP may have
more application within an organization, where security associations
are likely to be available;

(3)  URLs are being used in new ways, such as being embedded in config
files, where it is often a requirement that connections made based on
them be secure connections; in some situations the most common use of
a protocol may be with URL-initiated connections.

At this site we have heard loud and clear from users that we must
provide access controls on directory information.  We're already doing
this with crude mechanisms like domain-based filtering.  As we put
more sensitive information into the directory to enable more kinds of
applications, this requirement becomes even more important.  The model
is that an unauthenticated read of an entry will get a limited subset
of attributes; an authenticated access of the entry can get to more,
based on the authorization of the client.  Thus we expect
authenticated access to be the rule, not the exception, for those
users who are able to authenticate.  The fact that LDAP supports
authenticated access is one of its key features, for us.

We also expect that LDAP URLs will be commonly used:  embedded in web
pages, entered in config files, as attributes in the directory
itself.  It is a requirement that accesses using these URLs be
authenticated.

These observations lead us to believe that as we define URL schemes
for new protocols we should assume the use of strong authentication
and strong security rather than assuming their absence.  The key idea
is that a client interpreting a URL should have some ability to figure
out whether it can establish a secure, authenticated connection to the
server host in question, and what mechanism it should use to do so.
Policies might be something like:

   for server foo, use mechanism X

   for servers in domain foo.bar, use mechanism X, falling back to
   mechanism Y

   always use the TLS mechanism (equivalent to a ldaps: URL)

   use the last security mechanism used with the indicated server

etc.

There's a point made about server behavior too.  When using an
authentication mechanism, it may be that a client can authenticate
itself to the server, but the server has no authorization info for that
client.  For the scheme we propose here to work, servers should give such
sessions at least as much privilege as they give "anonymous" bind
sessions.

We note that this issue has an important relation to how LDAP over TLS
is handled.  We'll discuss that in a separate message. A third message (to
follow in a few days) will present proposed modifications to
draft-ietf-asid-ldapv3-url-02.txt and draft-ietf-asid-ldapv3-protocol-04.txt.

  - RL "Bob" Morgan
    Jeff Hodges
    Stanford


[2]  Subject: LDAP URLs and LDAP over TLS
From: Jeff Hodges <[e-mail]>
Date: Tue, 06 May 1997 14:51:18 -0700
To: [e-mail]
Cc: [e-mail], [e-mail]

In an another note we attempted to justify why the default behavior
when interpreting ldap:// URLs should be to establish secure,
authenticated connections if possible.  This suggestion is related to
the still unresolved (yes?) question about whether LDAP over TLS
should run on a separate port.  The current LDAP URL draft specifies a
"ldaps:" scheme in addition to a "ldap:" scheme.  The feature that
we're promoting, having the default URL provide some non-trivial
security, would in fact be provided by the ldaps: scheme, at least
based on the current default behavior of SSL implementations.  This
would be an attractive aspect of ldaps:.

But the URL usage that we envision exposes, we believe, the fatal flaw
of the separate port scheme.  What we'd like to be able to do is
specify a single URL that clients will use to establish secure
connections, if possible, across the entire range of clients.  But the
current SSL/TLS-on-separate-port schemes specify that there's a
"regular" port on which TLS *cannot* be used, and a foo-over-TLS port
on which TLS *must* be used.  If this usage is embedded in a ldap:
scheme and an ldaps: scheme, then a ldap: URL would exclude clients
that want to use TLS-based security, and an ldaps: URL would exclude
clients that don't do TLS.  So we can't have a universal, secure URL,
which is a big lose.

One approach to dealing with this is just to provide both kinds of
URLs in all locations (eg on web pages), and let users decide which to
use.  In fact that is the situation we're in with http: and https:
now.  We're sure we've all seen web pages that say "click here to use
our secure version".  In fact trying to provide the same content, or
more precisely, differing views into the same content, via http: and
https: is a tremendous pain, and shows the failure of this approach.

Another approach is to specify that clients should interpret all such
URLs as being ldap(s):, which is to say they should try the scheme
they prefer first no matter what the URL says.  This might work, but
it depends on clients being able to recover gracefully, and quickly,
when they try the wrong port first, which given current practice seems
to be asking a lot.

Another approach is based on the observation that, while SASL-based
authentication can be used over a TLS connection, if needed, the
current definition of the "regular" port prohibits TLS, so the TLS
port provides the more complete service.  So if we just specify that
all new clients must use TLS and the TLS port, any client can use any
available security mechanism.  This seems like a radical approach, but
maybe it has its defenders.

Lastly, we can, as John Myers has suggested, provide a way to
negotiate the use of TLS on the regular port.  This would enable TLS
and non-TLS clients to use the same port and the same URL with
whatever security scheme they prefer.  The cost is a modification to
the application protocol to do this, and probably an extra protocol
round-trip to do the negotiation.  It would still be possible to have
a separate TLS-specific port even if this feature were added;
presumably the question would be whether the possible confusion of
having two different ways of using TLS would be worth it.

It may be obvious that we're in favor of the last approach.

  - RL "Bob" Morgan
    Jeff Hodges
    Stanford


[3] Subject: LDAP URLs and security: proposed URL mods
From: [e-mail]
Date: Wed, 14 May 1997 11:03:43 -0700
To: [e-mail]
Cc: [e-mail], [e-mail]

Below are our suggested modifications to..

   draft-ietf-asid-ldapv3-url-02.txt.

..for supporting security policy expression in LDAP URLs and for establishing
conventions for client security behavior when no explicit policy is expressed
in a URL.

This proposal depends on "LDAP over TLS" being available on the standard LDAP
port. We feel that there are inherent issues with a scheme which maps
transport layer security and non-TLS-secured connections to separate ports,
even if the separate ports can be expressed in the URL. A prime component of
the issues being at what level should one negotiate application security: at
the application level or at the bare transport level? We feel it should be the
former.

Thanks,

Jeff Hodges
RL "Bob" Morgan
Stanford
--------------------------------------------------------------------------
Changes to draft-ietf-asid-ldapv3-url-02.txt...

3.  URL Definition				[revised section]

An LDAP URL begins with  the  protocol  prefix "ldap" and is defined by the
following grammar, which is based on the BNF defined in RFC 822 [9]:

     ldapurl       = "ldap://" ldapsession "/" ldapquery

     ldapsession   =
	[ [ dn ] [ ldaptls ] [ ldapsasl ] [ ldapsimple ] "@" ] hostport
     				; adapted from Section 5 of RFC 1738 [5]

     dn	          = distinguishedName
				; from Section 3 of [1]

     ; adapted from [7]...
     ldapsasl		= ";AUTH=" ( "*" / enc_auth_type )
     ldaptls		= ";TLS"
     ldapsimple		= ";SMPL"
     enc_auth_type    	= 1*achar	; see [10] for possible values

     achar            	= uchar / "&" / "=" / "~"
				; see [8] for "uchar" definition


     ldapquery		= [dn ["?" [attributes] ["?" [scope]
                  	  ["?" [filter]]]]]

     attributes		= attrdesc *("," attrdesc)
     scope		= "base" / "one" / "sub"
     attrdesc		= AttributeDescription 	; from Section 4.1.5 of [2]
     filter		= filter 		; from Section 4 of [4]


The dn is an LDAP Distinguished Name using the string format described
in [1]. In the ldapsession construct, it identifies the name of the directory
object the client should bind as. In the ldapquery production, it identifies
the base object of the LDAP search. See Section 4, below, for a discussion of
the semantics of the ldapsession construct.

The attributes construct is used to indicate which attributes should  be
returned  from  the  entry or entries.  Individual attrdesc names are as
defined for AttributeDescription in [2].   If  the  attributes  part  is
omitted, all attributes of the entry or entries should be requested.

The scope construct is used to specify the scope of the search  to  per-
form  in  the  given LDAP server.  The allowable scopes are "base" for a
base object search, "one" for a one-level search, or "sub" for a subtree
search.  If scope is omitted, a scope of "base" is assumed.

The filter is used to specify the search  filter  to  apply  to  entries
within  the specified scope during the search.  It has the format speci-
fied in [4].  If filter is omitted, a  filter  of  "(objectClass=*)"  is
assumed.

If the entry or entries reside in the X.500 namespace,  they  should  be
reachable from any LDAP server that is providing front-end access to the
X.500 directory. If the hostport part of the URL is missing, the URL can
be resolved by contacting any X.500-back-ended LDAP server.

Note that any URL-illegal characters (e.g.,  spaces)  and  the  reserved
character '?' occurring inside a dn, filter, or other element of an LDAP
URL MUST be escaped using the % method described in RFC 1738 [5].


4. LDAP URL User, Authentication, and Security Mechanisms  [new section]

A distinguished name and/or authentication mechanism(s) may be supplied (see
the ldapsession construct in section 3, above). After making the connection to
the LDAP server, the ldapsession construct is used in determining whether a
StartTLS and Bind operations should be carried out (see [2]). The
distinguished name, if supplied, MAY be used in authentication operations.

If no distinguished name or authentication and/or security mechanisms are
supplied, the program interpreting the URL SHOULD consult local policy
information to determine if an authenticated connection can be made to the
server, and what security mechanism and credentials to use.

    [this concept will be discussed further in a "Generic URL" ID
     to be released soon]
                                                             If so, it SHOULD
attempt to make such a connection, requesting appropriate credentials from the
mechanism and using StartTLS and Bind operations as necessary. If policy
does not indicate that a security mechanism can be used, then a Bind Operation
specifying the simple authentication option and zero length password MUST be
utilized (this results in an "anonymous session").

Authorization is not explicitly specified as a part of LDAP, but is a feature
of many implementations. A server SHOULD treat a session that is authenticated
but unauthorized as having at least the same privileges as an anonymous
session.  The default URL thus can offer privileged access to authorized
users, and unprivileged anonymous access to others.

Authentication and security mechanisms can be expressed by including an
ldapsession construct in the URL. ";TLS" indicates that the client SHOULD
request the server to start TLS on the connection (by performing a StartTLS
Operation). ";AUTH=<enc_auth_type>" indicates the client SHOULD request
appropriate credentials from that mechanism and use them in a Bind Operation
with the specified authentication mechanism. ";SMPL" indicates that the client
SHOULD request a password, and if not specified in the URL, a name from the
user, and then use them in a Bind Operation with the "simple" authentication
choice. If no distinguished name is specified, a one SHOULD be obtained from
the mechanism or requested from the user as appropriate. Some possible
combinations of ";TLS", ";AUTH=", and ";SMPL" may be inappropriate, but none
are specifically excluded (see section 5).

The string ";AUTH=*" indicates that the client SHOULD select an
appropriate SASL mechanism. The client may determine the SASL mechanisms
supported by the server by reading the supportedSASLMechanisms of the server's
rootDSE. It may combine these options with local policy information, if any,
in order make that choice. If no user name is specified and no appropriate
authentication mechanisms are available, the client SHOULD cease processing
the URL without initiating a connection.

Note that if unsafe or reserved characters such as " " or ";" are present in
the user name or authentication mechanism, they MUST be encoded as described
in RFC 1738 [8].


5.  Security Considerations				[revised section]

Security considerations discussed in the LDAP specification [2] and the URL
specification [8] are relevant.

The LDAP URL format allows the specification of a client identity, plus
security and authentication methods. A client SHOULD NOT utilize a simple
password form of authentication over an insecure connection without first
alerting the user about the connection's insecurity.

A client MAY attempt to achieve TLS and/or SASL security during a session
started from resolving an "ldap:" URL regardless of the absence of either of
the TLS or AUTH keywords. Client implementors SHOULD be careful when selecting
an authentication mechanism if ";AUTH=*" is specified without a user name.
Clients SHOULD NOT fall back to a simple authentication component of the Bind
operation if the connection is insecure. Clients who do so are vulnerable to
an active attacker masquerading as the server and does not declare support for
any of the stronger security and authentication mechanisms.

The LDAP URL format allows the specification of an arbitrary LDAP search
operation  to  be  performed when evaluating the LDAP URL.  Following an
LDAP URL may cause unexpected results, for  example,  the  retrieval  of
large  amounts of data, the initiation of a long-lived search, etc.  The
security implications of resolving an LDAP URL are the same as those  of
resolving an LDAP search query, and are discussed in the protocol
specification [2].



[new references]

[7]  IMAP URL Scheme, C. Newman,  draft-newman-url-imap-07.txt, May 1997.

[8]  Berners-Lee, Masinter, McCahill, "Uniform Resource
      Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of
      Minnesota, December 1994, <URL:ftp://ds.internic.net/rfc/rfc1738.txt>

[9]  D. Crocker, "Standard of the Format of ARPA-Internet Text
      Messages", STD 11, RFC 822, August 1982.

[10] J. Myers, "Simple Authentication and Security Layer (SASL)",
      draft-myers-auth-sasl-10.txt, April 1997