Subject: authmeth-16 TLS issues

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 20 Oct 2005 07:32:26 +0200

3.1. Sequencing of the StartTLS Operation

This header name seems poor, sections 3.1.* describe much more than
sequencing.  It's mostly 3.1.1 which talks about that - except that the
actions described in sections 3.1.* should be performed in the sequence
they occur in in the draft.

3.1.1. StartTLS Request
3.1.2. StartTLS Response

If last sentence of 3.1.2 is moved to [protocol] as I suggested in
thread "[Protocol] clarification on StartTLS resonse", maybe these two
sections should be merged.  There wouldn't be much left of 3.1.2, and
3.1.1 already talks a bit about the response anyway.

3.1.5. Server Identity Check

Why are the checks to perform ordered?  The order seems irrelevant
since there is no "fail and don't check anything else" step.

If the reason is that clients can derive a security factor or something
from which identity was used, please mention that.

But if so, I wonder a bit about CN vs. subjectAltName.  If the CN is an
exact match and the subjectAltName is either a wildcard match or matches
via a derived name, the CN would be a more reliable match and should be
done first.  Or...?

3.1.5.1. Comparison of DNS Names

> "If the reference identity is an internationalized domain name,
> conforming implementations MUST convert it to the ASCII Compatible
> Encoding (ACE) format as specified in section 4 of RFC 3490 [RFC3490]
> before comparison with subjectAltName values of type dNSName."

Only for subjectAltName:dNSName, not for CN?

If that's deliberate and certificate CNs may not contain
internationalized domain name, I suggest this is mentioned explicitly.

-- 
Hallvard

---

From: "Roger Harrison" <[email-masked]>
Date: Thu, 20 Oct 2005 08:13:41 -0600

> sequencing.  It's mostly 3.1.1 which talks about that ‑ except that the 

I've renamed Section 3.1 to TLS Establishment Procedures. 

> thread [Protocol] clarification on StartTLS resonse, maybe these two 
> 3.1.1 already talks a bit about the response anyway 

I agree. I've removed section 3.1.2 

> since there is no fail and don't check anything else step. 

There is some preference in the order. Typically, the original value of the reference identity is the most authoritative information available to the client regarding the server's identity and thus is preferred over other forms of that identity to which it can be mapped.  I believe the intent behind this preference is adequately implied with the text in step 2 indicating that only secure mappings should be used. The use of the subjectName value in step three is deprecated and thus should be used as a last resort. Thus the comparison with subjectAltName values in steps 1 and 2 are preferred ahead of step 3. 

> via a derived name, the CN would be a more reliable match and should be 

I don't understand all of the history behind this, but the use of subjectName appears to be deprecated widely. The RFC on secure HTTP (I don't have the RFC # handy) explicitly deprecates using subjectName and favors the use of subjectAltName.  In speaking with the certificate expert in Novell's security team in preparation to rewrite the server identity check section, I received the same feedback. If you'd like me to track down specifics on the reasoning, I could do so. 

> > If the reference identity is an internationalized domain name, 
> > before comparison with subjectAltName values of type dNSName. 
> 

The text in step 3 says that the comparison [of the commonName value of the RDN from the subjectName] is performed using the [rules for] comparison of DNS names in section 3.1.5.1.  I assumed that if the CN value was an IDN that the IDN rules would take effect as part of the check. Perhaps we need to say something about how to tell if the CN value is an IDN as well?  I'm not familiar with how one determines the difference. Do you know? 

> ‑‑  

Roger

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 20 Oct 2005 17:41:22 +0200

Roger Harrison writes:
> There is some preference in the order. Typically, the original value of
> the reference identity is the most authoritative information available
> to the client regarding the server's identity and thus is preferred over
> other forms of that identity to which it can be mapped.  I believe the
> intent behind this preference is adequately implied with the text in
> step 2 indicating that only secure mappings should be used.

No - I cannot find anything in the draft which will behave differently
if the client chooses to disobey the specified ordering of the check.
What's the point of making a certain behaviour an error if that
behaviour is indistinguishable from the correct behaviour?

Which is why I asked/suggested:

> I don't understand all of the history behind this, but the use of
> subjectName appears to be deprecated widely.  The RFC on secure HTTP
> (I don't have the RFC # handy) explicitly deprecates using subjectName
> and favors the use of subjectAltName.

s/subjectName/commonName/.

I don't see how that affects the argument above, though.  If the
implementation supports checking CN or subjectName at all and that is
more precise than the subjectAltName, then that is still the best match.
Of course fit could just be that I guessed wrong the reason to have an
ordering.

I don't see a reason in RFC 2818 for the ordering either.

> In speaking with the certificate
> expert in Novell's security team in preparation to rewrite the server
> identity check section, I received the same feedback. If you'd like me
> to track down specifics on the reasoning, I could do so.

I have no objection to deprecating cn or subjectName or whatever,
it's the logic of what [authmeth] does about it I can't figure out.

> The text in step 3 says that the comparison [of the commonName value of
> the RDN from the subjectName] is performed using the [rules for]
> comparison of DNS names in section 3.1.5.1.  I assumed that if the CN
> value was an IDN that the IDN rules would take effect as part of the
> check. Perhaps we need to say something about how to tell if the CN
> value is an IDN as well?  I'm not familiar with how one determines the
> difference. Do you know?

Not a clue.

-- 
Hallvard

---

From: "Roger Harrison" <[email-masked]>
Date: Thu, 20 Oct 2005 12:49:50 -0600

Hallvard, 

You've persuaded me to rethink my approach to the server identity check section.  I've made some adjustments to remove the ordering. Here's my proposed replacement for rules 1-3 in the -16 draft: 

The client determines the type (e.g. DNS name or IP address) of the reference identity and performs a comparison between the reference identity and each subjectAltName value of the corresponding type until a match is produced.  Once a match is produced, the server's identity is verified and the server identity check is complete. Different subjectAltName types are matched in different ways.  Sections 3.1.3.1-3.1.3.3 explain how to compare various types of subjectAltName. 

The client may map the reference identity to a different type prior to performing a comparison. Mappings may be performed for all available subjectAltName types to which the reference identity can be mapped, however the reference identity should only be mapped to types for which the mapping is either inherently secure (e.g. extracting the DNS name from a URI to compare with a subjectAltName of type dNSName) or for which the mapping is performed in a secure manner that is not subject to attack (e.g. using DNSSec, or using user- (or admin-) configured host-to-address/address-to-host lookup tables). 

The server's identity may also be verified by comparing the reference identity to the Common Name value of the least significant RDN of the subjectName field of the server's certificate.  Note that the TLS implementation may display DNs in certificates according to X.509's rules rather than LDAP's rules.  For example, RDNs in a DN may be ordered left‑to‑right instead of right‑to‑left.  This comparison is performed using the rules for comparison of DNS names in section 3.1.3.1 below, with the exception that no wildcard matching is allowed.  Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to provide subjectAltName values instead. 

Does this work? 

Roger

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 20 Oct 2005 22:16:37 +0200

Roger Harrison writes:
> You've persuaded me to rethink my approach to the server identity
> check section.  I've made some adjustments to remove the
> ordering. Here's my proposed replacement for rules 1-3 in the -16
> draft:

Looks good, except for a few wording nitpicks.  (Haven't had time to
check it against other recent authmeth comments though.)

> The client determines the type (e.g. DNS name or IP address) of the
> reference identity and performs a comparison between the reference
> identity and each subjectAltName value of the corresponding type until
> a match is produced.  Once a match is produced, the server's identity
> is verified and the server identity check is complete.

s/is verified/has been verified/.

(It needs a different tense from the surrounding text, so it
doesn't look like something else the client should do.)

> The server's identity may also be verified by comparing the reference
> identity to the Common Name value of the least significant RDN of the
> subjectName field of the server's certificate.  Note that the TLS
> implementation may display DNs in certificates according to X.509's
> rules rather than LDAP's rules.  For example, RDNs in a DN may be
> ordered left-to-right instead of right-to-left.

I still think "the RDN" is clearer than "the least significant RDN",
since I'm not used to the term "least significant" with this meaning for
non-numbers.  That goes poorly with the last sentence of the "RDNs" in
the DN though.  s/RDNs/components/ in last sentence would allow for it,
but I'm not quite sure that's an improvement.

-- 
Hallvard

---

From: Howard Chu <[email-masked]>
Date: Thu, 20 Oct 2005 13:52:09 -0700

>> ordered left-to-right instead of right-to-left.

Upon further reflection, I would make this

   Note that the TLS
   implementation may display DNs in certificates according to X.509's
   conventions rather than LDAP's rules.

as there really are no rules in X.500 for displaying DNs.

> non-numbers.

Another choice could be "most inferior" though it's not much better. 
But, both terms are in keeping with the X.500 definition of a DN.

I guess "the RDN" is better if it is more explicitly qualified:

   The server's identity may also be verified by comparing the reference
   identity to the value of the Common Name attribute in the RDN of the
   entity named by the server certificate's DN.

I.e., a DN is a sequence of RDNs, but only one RDN names the entity in 
question, the others name the parents/ancestors.

-- 
   -- 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: Hallvard B Furuseth <[email-masked]>
Date: Thu, 20 Oct 2005 23:14:46 +0200

> as there really are no rules in X.500 for displaying DNs.

Sorry about that, I forgot to deal with that in my suggestion.  Still,
the left-to-right vs right-to-left issue has caused confusion, as
someone mentioned.  Is this (in addition to your sentence) better?

     For example, some X.500 implementations order <RDNs in a DN, or
     DN components, or whatever - see below> left-to-right instead
     of LDAP's right-to-left.

>> since I'm not used to the term "least significant" with this meaning for

I withdraw that suggestion, I forgot that "the RDN" is unique for entity
and not for a DN, as Howards mentions below.

> But, both terms are in keeping with the X.500 definition of a DN.

Does seem a bit better.  Anyway, if both are X.500 terms I guess there
isn't much to do.

>    entity named by the server certificate's DN.

No - that may lead some people to believe the named entity must exist in
the local LDAP directory.

-- 
Hallvard

---

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 20 Oct 2005 22:56:43 -0600

Leaf RDN is another possibility

>>> Howard Chu <[email-masked]> 10/20/05 2:52:09 pm >>>

   Note that the TLS

   The server's identity may also be verified by comparing the
reference
   identity to the value of the Common Name attribute in the RDN of
the
   entity named by the server certificate's DN.

---

From: "Roger Harrison" <[email-masked]>
Date: Fri, 21 Oct 2005 20:50:17 -0600

I've reworked this paragraph on the CN/subjectName check based on several comments in this thread. Here's what I now have: 

The server's identity may also be verified by comparing the reference identity to the Common Name value in the leaf RDN of the subjectName field of the server's certificate.  Note that the TLS implementation may display DNs in certificates according to X.509 conventions.  For example, some X.500 implementations order the RDNs in a DN using a left-to-right (most significant to least significant) convention instead of LDAP's right‑to‑left convention.  This comparison is performed using the rules for comparison of DNS names in section 3.1.3.1 below, with the exception that no wildcard matching is allowed.  Although the use of the Common Name value is existing practice, it is deprecated and Certification Authorities are encouraged to provide subjectAltName values instead. 

Comments and feedback are welcome. 

Roger

>>> Hallvard B Furuseth <[email-masked]> 10/20/05 3:14 pm >>>

>> I still think the RDN is clearer than the least significant RDN,
>> since I'm not used to the term least significant with this meaning for
>> non-numbers.

I withdraw that suggestion, I forgot that the RDN is unique for entity
and not for a DN, as Howards mentions below.

> Another choice could be most inferior though it's not much better.

> I guess the RDN is better if it is more explicitly qualified:
>

--
Hallvard

---

From: Howard Chu <[email-masked]>
Date: Sat, 22 Oct 2005 12:00:05 -0700

Roger Harrison wrote:
> 
> 
> I've reworked this paragraph on the CN/subjectName check based on 
> several comments in this thread. Here's what I now have:
> 
> identity to the Common Name value in the leaf RDN of the subjectName 
> field of the server's certificate.  Note that the TLS implementation may 
> display DNs in certificates according to X.509 conventions.  For 
> example, some X.500 implementations order the RDNs in a DN using a 
> left-to-right (most significant to least significant) convention instead 
> of LDAP's right‑to‑left convention.  This comparison is performed using 
> the rules for comparison of DNS names in section 3.1.3.1 below, with the 
> exception that no wildcard matching is allowed.  Although the use of the 
> Common Name value is existing practice, it is deprecated and 
> Certification Authorities are encouraged to provide subjectAltName 
> values instead.
> 

I think the wording is good; the flow is a bit choppy. Perhaps the Note 
should be at the end of the paragraph, or a separate paragraph:

The server's identity may also be verified by comparing the reference
identity to the Common Name value in the leaf RDN of the subjectName
field of the server's certificate. This comparison is performed using
the rules for comparison of DNS names in section 3.1.3.1 below, with the
exception that no wildcard matching is allowed.  Although the use of the
Common Name value is existing practice, it is deprecated and 
Certification Authorities are encouraged to provide subjectAltName
values instead. Note that the TLS implementation may display DNs in 
certificates according to X.509 conventions.  For example, some X.500 
implementations order the RDNs in a DN using a left-to-right (most 
significant to least significant) convention instead of LDAP's 
right‑to‑left convention. Implementers should not blindly assume the 
left-most RDN is the leaf RDN.

---

From: "Roger Harrison" <[email-masked]>
Date: Sat, 22 Oct 2005 18:16:51 -0600

Howard,
 
Thanks for the suggestion. I was thinking the very same thing myself last night, and I've now changed the flow of the paragraph as you suggested.
 
Roger

>>> Howard Chu <[email-masked]> 10/22/2005 1:00 pm >>>