Subject: WG Last Call: draft-ietf-ldapbis-authmeth-15.txt

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 06 Sep 2005 13:10:36 -0700

This message initiates a LDAPBIS Working Group Last Call on the
document:

  Title:     LDAP: Authentication Methods and 
             Connection Level Security Mechanisms
  Editor:    R. Harrison
  Filename:  draft-ietf-ldapbis-authmeth-15.txt

The purpose of this WG Last Call is to ensure that the Working
Group has achieved consensus that the document is suitable for
publication on the Standards Track.

Please review the document for both technical and editorial
problems.  Technical issues should be discussed on this list.
Editorial issues may be sent to the document editor.

The Last Call period will close on Thursday, 22 September 2005.

Upon completion of the last call, the WG chair(s) will take
action based upon the consensus of the WG.  Possible actions
include:

  1) recommending to the IETF Applications Area Directors
     that the document, after possible editorial or
     other minor changes, be considered by the IESG
     for publication as a Standard Track RFC
     (which generally involves an IETF-wide Last Call); or

  2) requiring that outstanding issues be adequately
     addressed prior to further action (including,
     possibly, another WG Last Call).

Remember that it is our responsibility as Working Group members
to ensure the quality of our documents and of the Internet
Standards process.  So, please read and comment!

Kurt Zeilenga, LDAPBIS WG co-chair

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 13 Sep 2005 22:47:49 +0100

>publication on the Standards Track.
Excuse me for bringing the following issue so late. There is some text 
about DIGEST-MD5 in draft-ietf-ldapbis-authmeth-15.txt that bothers me:

 >10. SASL DIGEST-MD5 Authentication Mechanism
 >
 >   Support for subsequent authentication ([DIGEST-MD5] section 2.2) is
 >   OPTIONAL in clients and servers.

The sentence seem to be trying to update definition of DIGEST-MD5 SASL 
mechanism. This goes against "a protocol profile SHOULD NOT attempt to 
amend the definition of mechanisms" statement in the SASL document.
If there is an interoperability problem due to the lack of the quoted 
sentence, then perhaps the DIGEST-MD5 document is a better place to 
address it.

Alexey

---

From: "Roger Harrison" <[email-masked]>
Date: Thu, 15 Sep 2005 15:17:36 -0600

>sentence, then perhaps the DIGEST-MD5 document is a better place to 

The text in question from authmeth-15 dates back to RFC 2829, so I can
only speculate on the reason for including it. I imagine it was included
to provide the information without requiring the user to dig into the
DIGEST-MD5 document. 

With careful reading, it appears that the DIGEST-MD5 document already
states that neither client nor server is required to support subsequent
authentication even when the protocol profile allows it, so this text
does not change the intent of DIGEST-MD5. 

I can see some options:

1. Leave text as-is.  Probably not satisfactory, particularly due to
the OPTIONAL keyword being used in the sentence.

2. Modify text to remove keyword. Possible new text: "Note that
DIGEST-MD5 does not require clients or servers to support subsequent
authentication ([DIGEST-MD5] section 2.2)."

3. Remove the text altogether and let people deduce this fact by
reading [DIGEST-MD5]. 

I prefer #2 and would consider #3 if the text in [DIGEST-MD5] were made
more explicit regarding the optional nature of subsequent authentication
support.

>Alexey 
 
Roger

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 16 Sep 2005 19:30:02 +0100

Roger Harrison wrote:

>> <>about DIGEST-MD5 in draft-ietf-ldapbis-authmeth-15.txt that bothers 
>> me:
>
>>> <>10. SASL DIGEST-MD5 Authentication Mechanism
>>>
Right.

>more explicit regarding the optional nature of subsequent authentication
I think #2 is sensible: you need to make clear that this is not an 
additional requirement, but just an extract from the DIGEST-MD5 document.

---

From: "Roger Harrison" <[email-masked]>
Date: Mon, 19 Sep 2005 07:47:19 -0600

I've made the change using option #2. 

Roger

>>> Alexey Melnikov <[email-masked]> 09/16/05 8:30 pm >>>
Roger Harrison wrote:

>>mechanism. This goes against a protocol profile SHOULD NOT attempt to
>>   
>>
>>amend the definition of mechanisms statement in the SASL document.
Right.

>2. Modify text to remove keyword. Possible new text: Note that
>authentication ([DIGEST-MD5] section 2.2).
>
I think #2 is sensible: you need to make clear that this is not an
additional requirement, but just an extract from the DIGEST-MD5
document.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 19 Sep 2005 10:27:34 -0700

Please note this WGLC closes this Thursday!  Please review
and comment (and if you have no comments, drop a note to
chairs so).

-- Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 22 Sep 2005 12:21:52 -0700

The WGLC will now close on Tuesday, 27 September 2005.
It is hoped that this extension will allow for additional
review and comment.  If you haven't commented already,
please take some time in the next few days to do so.

Thanks, Kurt

---

From: Howard Chu <[email-masked]>
Date: Thu, 22 Sep 2005 13:39:44 -0700

Section 3.1.4 Discovery of Resultant Security Level
This refers to 3.2.3 which does not exist. I can't tell what it was 
intended to reference.

Also there are many references to [Protocol] section 4.13.x.x which 
probably should now be 4.14.xx.

Section 3.1.5 Server Identity Check
This section talks about how a client must verify a server's name 
against the identity presented in the server's certificate. This clause
  - The "*" wildcard character is allowed in the server name
        provided by the user.  If present, it matches only the left-most
        label from the subjectAltName.
makes no sense to me. That implies that I can issue an ldap request to 
e.g. ldap://*.example.com, which at a glance means to perform a DNS zone 
transfer against example.com and then issue an LDAP query against every 
DNS host record that's returned. I don't see how it makes any sense for 
a user to provide wildcarded server names to a client. In RFC2830 it was 
clear that wildcard characters could be present in the certificate, and 
that usage makes sense. Why is the use of wildcards reversed here? This 
invalidates many already-deployed RFC2830-conforming server 
certificates, if nothing else.

Section 3.3
2nd bullet
	"confidentially" should be "confidentiality"

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   OpenLDAP Core Team            http://www.openldap.org/project/

---

From: Howard Chu <[email-masked]>
Date: Thu, 22 Sep 2005 14:09:12 -0700

Section 7 1st paragraph, 5th line
	s/the the/the/

Also this paragraph is a little ambiguous, it might be better as

    An LDAP client may use the unauthenticated authentication mechanism
    of the simple Bind choice to establish an anonymous authorization
    state by sending a Bind request with a name value (a distinguished
    name in LDAP string form [LDAPDN]) of non-zero length, ...

Otherwise it implies that a sequence of two names be provided.

2nd paragraph, 1st line
	s/not used in/not used/

The same ambiguity about name values appears in Section 8 paragraph 1.

Section 9.2 2nd paragraph "with the same sasl" [mechanism] "sasl" should 
be "SASL"

In general, capitalization of terms (like bind vs Bind) appears very 
inconsistent; it becomes a distraction when reading the document.

The 3rd paragraph
	LDAP servers use the serverSaslCreds field, an OCTET STRING,
	in a BindResponse message to transmit each challenge.
	...
	LDAP clients use the credentials field, an OCTET STRING, in
	the SaslCredentials sequence ...

Same complaint as for section 7 & 8, would prefer:
	LDAP servers use the serverSaslCreds field (an OCTET STRING)
	in a BindResponse message ...

6th paragraph s/client t/client to/

---

From: Howard Chu <[email-masked]>
Date: Thu, 22 Sep 2005 14:31:15 -0700

> please take some time in the next few days to do so.

Section 12.2 Password-related Security Considerations
"clear text" and "cleartext" are used in paragraph 1. Pick one and stick 
with it.

Section 12.2 StartTLS Security Considerations
section numbering needs to be straightened out

paragrah 2 line 1 s/though/through/

Section 12.4 Simple Mechanism Security Considerations
line 3 s/do not disclose/do not disclose the/

Appendix A.
presumably this is non-normative.

The Introduction section 1, last paragraph says
	Appendix B contains example deployment scenarios ...
but none of the Appendices provide any example scenarios.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 22 Sep 2005 23:52:43 +0200

Howard Chu writes:
> DNS host record that's returned. (...)

The following seems to have kind of reversed logic too:

>      - If a subjectAltName extension of type dNSName is present in the
>        certificate, it MUST be used as the source of the server's
>        identity.

This is wrong if the user provided an IP address and not a name.

>        Otherwise, if a subjectAltName extension of type
>        iPAddress is present in the certificate it SHOULD be used as the
>        source of the server's identity.  Implementations MAY support
>        the use of other subjectAltName types as sources of the server's
>        identity.

Given the "Otherwise..." above, it seems clear that if subjectAltName is
present in the certificate, iPAddress shall not be used even if it is
present too.  Thus, if one has ldap.example.com in the certificate,
one cannot connect to its IP address as well.

Also, it no longer seems to be an option to use the name in the CN, even
if there is no subjectAltName.  The above text is stricter about
alternatives.  Also the specification of dNSName in the next sentence
does not allow for anything else:

>    If the server name does not match the dNSName-based identity in the
>    certificate per the above check, user-oriented clients SHOULD either
>    notify the user (clients may give the user the opportunity to
>    continue with the LDAP session in this case) or close the transport
>    connection and indicate that the server's identity is suspect.

I think this sentence should be swapped a bit: Clients SHOULD indicate
that the server's identity is suspect and either notify ... or close
the transport connection.

BTW, the above dNSName should at least be relaxed to subjectAltname, to
be consistent with the rest of the text.  Though as you see I think that
too is too strict.

>    Automated clients SHOULD close the connection and then return and/or
>    log an error indicating that the server's identity is suspect.

---

From: "Roger Harrison" <[email-masked]>
Date: Mon, 26 Sep 2005 11:19:54 -0600

Thanks for the review, Howard. I've incorporated all of these
suggestions into the -16 draft. 

Roger

>>> Howard Chu <[email-masked]> 09/22/05 3:09 pm >>>

2nd paragraph, 1st line
s/not used in/not used/

Section 9.2 2nd paragraph with the same sasl [mechanism] sasl should
be SASL

The 3rd paragraph

---

From: "Roger Harrison" <[email-masked]>
Date: Mon, 26 Sep 2005 11:26:44 -0600

Howard, 

Thanks for these suggestions. I have incorporated all of them into the
authmeth-16 revision. 

Roger 

>>> Howard Chu <[email-masked]> 09/22/05 3:31 pm >>>

Section 12.2 Password-related Security Considerations
clear text and cleartext are used in paragraph 1. Pick one and stick
with it.

Appendix A.

---

From: "Roger Harrison" <[email-masked]>
Date: Mon, 26 Sep 2005 14:53:52 -0600

>probably should now be 4.14.xx. 

I fixed the broken references. Thanks for catching them. 

>  ‑ The * wildcard character is allowed in the server name 
>        provided by the user.  If present, it matches only the left‑most 
>invalidates many already‑deployed RFC2830‑conforming server 

You are correct. The * wildcard character can be included in DNS names in the certificate rather than in the server name provided by the user. I apologize for reversing it.  This will be fixed in authmeth-16 

> 
>Section 3.3 
>2nd bullet 
>confidentially should be confidentiality 

Got it. 
[snipped out original request from Kurt here] 

>‑‑  
>   ‑‑ Howard Chu 

Roger