Subject: Please publish this I-D: draft-ietf-ldapext-ldapv3-tls-06.txt

From: [email-masked]
Date: Thu, 10 Feb 2000 09:17:11 -0800

This revision of draft-ietf-ldapext-ldapv3-tls has only minor editorial 
changes, plus a clarification at the end of section 4.6 as a result of 
Security Area review. The extraneous section 6 fragment was removed (we'd moved
that entire section to draft-ietf-ldapext-authmeth-04), and remaining sections 
renumbered.

JeffH

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 10 Feb 2000 10:12:38 -0800

Jeff,

I have only significant concern.

In 6.1.2:
	[Upon failure of BIND SASL/EXTERNAL...]
	The LDAP association's authentication identity and
       authorization identity (if any) which were in effect
       after TLS establishment but prior to making the Bind request,
       MUST remain in force.

This is inconsistent with RFC 2251 prescribed behavior:
  Clients MAY send multiple bind requests on a connection to change
  their credentials. ...  Authentication from earlier binds
  are subsequently ignored, and so if the bind fails, the connection
  will be treated as anonymous.

I can find no compelling reasoning why BIND failure whilst
TLS is enabled should have special behavior.  I believe this an
unnecessary complication.  I believe there are many good reasons
why this BIND behavior should be consistent without regard to TLS
(or IPSEC or whatever).  Reasons: simplicity of specification,
implementation, and use.

The general rule for security is simplicity.  Why the complication?

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Tue, 15 Feb 2000 14:14:39 -0800 (PST)

As Kurt has pointed out (and first pointed out back in November),
there is a difference between RFC 2251 and
draft-ietf-ldapext-ldapv3-tls-06.txt on the question of what the client
authentication/authorization state should be after a failed bind
attempt.  2251 (last paragraph of 4.2.1) says:

   Clients MAY send multiple bind requests on a connection to change
   their credentials.  A subsequent bind process has the effect of
   abandoning all operations outstanding on the connection.  (This
   simplifies server implementation.)  Authentication from earlier binds
   are subsequently ignored, and so if the bind fails, the connection
   will be treated as anonymous.

Call this the "revert-to-anonymous" approach.  Whereas ldapv3-tls-06
(first paragraph of 6.1.2.3) says:

  For either form of assertion, the server MUST verify that the client's
  authentication identity as supplied in its TLS credentials is permitted
  to be mapped to the asserted authorization identity. The server MUST
  reject the Bind operation with an invalidCredentials resultCode in the
  Bind response if the client is not so authorized. The LDAP association's
  authentication identity and authorization identity (if any) which were
  in effect after TLS establishment but prior to making the Bind request,
  MUST remain in force.

Call this the "leave-as-is" approach.  (The same language appears in
the second paragraph too.)

The intention never was to have different behavior for different kinds
of binds.  Some of us (Jeff and Bob) think that the leave-as-is
approach is the right thing to do for all failed binds, since it's
more intuitive (to us), consistent with other practice (eg "su" on
UNIX), and produces a cleaner state diagram.  However, upon reflection
these arguments don't seem compelling enough to change the behavior
that is in RFC 2251, especially at this point when a revised 2251
isn't even on the table.  We do think it's worthy of discussion when
2251 is revised, though.

We also don't want this issue to hold up the issuance of the set of
security docs (draft-ietf-ldapext-authmeth-04.txt,
draft-ietf-ldapext-ldapv3-tls-06, draft-leach-digest-sasl-05.txt)
which this WG has been working on for over two years, and which will
remove the IESG warning from the front of RFCs 2251-56.  These docs
have already been through WG and IETF last calls, and IESG review, and
are very close to going to RFC.

So, we propose that section 6.1.2.3 in draft-ietf-ldapext-ldapv3-tls-06
be changed to reflect the revert-to-anonymous approach; new text is
appended to this message.

This is a small but substantive change which will require a new (-07)
version of the ldapv3-tls draft.  Rather than go through another full
last call we suggest waiting a week from today for comments on this
change, then telling the Area Directors to go forward with
ldapv3-tls-07 for publication.

Comments, please.

 - RL "Bob" Morgan
   Jeff Hodges
   Mark Wahl

---

6.1.2.3.  Error Conditions

  For either form of assertion, the server MUST verify that the client's
  authentication identity as supplied in its TLS credentials is permitted
  to be mapped to the asserted authorization identity. The server MUST
  reject the Bind operation with an invalidCredentials resultCode in the
  Bind response if the client is not so authorized. 

  Additionally, with either form of assertion, if a TLS session has not
  been established between the client and server prior to making the SASL
  EXTERNAL Bind request and there is no other external source of authenti-
  cation credentials (e.g.  IP-level security RFC 1825), or if, during the
  process of establishing the TLS session, the server did not request the
  client's authentication credentials, the SASL EXTERNAL bind MUST fail
  with a result code of inappropriateAuthentication.

  After the above Bind operation failures, any client authentication
  and authorization state of the LDAP association is lost, so the LDAP
  association is in an anonymous state after the failure.  TLS
  connection state is unaffected, though a server MAY end the TLS
  connection, via a TLS close_notify message, based on the Bind
  failure (as it MAY at any time).

---

From: [email-masked] (Mark C Smith)
Date: Wed, 16 Feb 2000 10:20:46 -0500

I support your proposal.  We definitely need to specify consistent
behavior in the face of failed binds (thanks to Kurt for noticing the
discrepancy).  I think it is too late to change LDAPv3's behavior (as
specified in 2251) since clients likely exist that rely on the
"revert-to-anonymous" behavior it specifies... but that is an argument
for another later day.

-- 
Mark Smith
Directory Product Development / iPlanet E-Commerce Solutions
My words are my own, not my employer's.            Got LDAP?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 16 Feb 2000 09:18:41 -0800

Bob, Jeff, MarkW,

The suggested change to the TLS draft appears to be fine.  Note
that the AuthMeth draft will need a similar change (last sentence
of section 10).

Though I too would like to see these drafts progressed quickly,
we must not be too hasty.  As you noted, the change is
"substantive."  As such, I believe it prudent to have yet another
WG last call.  I also believe it quite likely that the IESG will
require another IETF wide last call because the documents were
revised multiple times, including a number of "substantive"
changes, multiple subsequent WG last calls were made after
the IETF wide last call, and just the fact that the previous
IETF wide call completed some time ago.

	Kurt

---

From: Mark Wahl <[email-masked]>
Date: Wed, 16 Feb 2000 11:26:27 -0600

Once the LDAPEXT review is done, the Apps Area Directors will let us know what 
to do next with the draft.  I'll let the list know what the result is.

Mark Wahl, Directory Product Architect
Innosoft International, Inc.