Subject: [IPsec] Populating ID_DER_ASN1_DN

From: David Wierbowski <[email-masked]>
Date: Wed, 16 Sep 2009 22:33:14 -0400

Section 3.1.5 of RFC 4945 states that when generating an ID type of
ID_DER_ASN1_DN that "implementations MUST populate the contents of ID with
the Subject field from the end-entity certificate, and MUST do so such that
a binary comparison of the two will succeed."  Section 3.1.5 is specific to
IKEv1.  There is no such requirement listed in Section 4 which is
applicable to IKEv2.

What is the purpose of this requirement and why is it only applicable to
IKEv1?

I believe in the past it has been said that the requirement exists because
smaller devices may not be capable of performing DN matching.  If that's
the case it seems the issue would be applicable to IKEv2 as well.

Section Section 3.1.5 also states, "Regarding SPD matching, implementations
MUST be able to perform  matching based on a bitwise comparison of the
entire DN in ID to its entry in the SPD.  However, operational experience
has shown that using the entire DN in local configuration is difficult,
especially in large-scale deployments.  Therefore, implementations also
MUST be able to perform SPD matches of any combination of one or more of
the C, CN, O, OU attributes within Subject DN in the ID to the same in the
SPD."

What is the purpose of requiring the ability to match on a  bitwise
comparison of the entire DN if it is also acceptable to match any
combination of one or more of the C, CN, O, OU attributes?  It seems that
only implementing the second MUST would be sufficient.  If the ID matches a
bitwise comparison of the entire DN it will also match a combination of one
or more of the C, CN, O, OU attributes.

Dave Wierbowski

---

From: Raj Singh <[email-masked]>
Date: Thu, 17 Sep 2009 08:14:49 +0530

Hi David,

On Thu, Sep 17, 2009 at 8:03 AM, David Wierbowski <[email-masked]>wrote:

> IKEv1. There is no such requirement listed in Section 4 which is applicable
> to IKEv2.
>
> smaller devices may not be capable of performing DN matching. If that's the
> case it seems the issue would be applicable to IKEv2 as well.
>
> MUST be able to perform matching based on a bitwise comparison of the entire
> DN in ID to its entry in the SPD. However, operational experience has shown
> that using the entire DN in local configuration is difficult, especially in
> large-scale deployments. Therefore, implementations also MUST be able to
> perform SPD matches of any combination of one or more of the C, CN, O, OU
> attributes within Subject DN in the ID to the same in the SPD."
>
> The entire match is required for tighter security and one certificate not
being used by many users (if they have exportable private keys). Normally,
CN contains info which is specific to the certificate users. If we match
only O, OU that will be same for whole organization. In this case User A who
has exportable private key can share it's certificate with User B and
authentication will be successful.

This is just one of case.

> Dave Wierbowski
>
>
>
>
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
Thanks,
Raj

---

From: Yoav Nir <[email-masked]>
Date: Thu, 17 Sep 2009 09:50:09 +0300

On Sep 17, 2009, at 5:33 AM, David Wierbowski wrote:

> ID_DER_ASN1_DN that "implementations MUST populate the contents of  
> ID with the Subject field from the end-entity certificate, and MUST  
> do so such that a binary comparison of the two will succeed."  
> Section 3.1.5 is specific to IKEv1. There is no such requirement  
> listed in Section 4 which is applicable to IKEv2.
>
> What is the purpose of this requirement and why is it only  
> applicable to IKEv1?
>
> I believe in the past it has been said that the requirement exists  
> because smaller devices may not be capable of performing DN  
> matching. If that's the case it seems the issue would be applicable  
> to IKEv2 as well.
>
> Section Section 3.1.5 also states, "Regarding SPD matching,  
> implementations MUST be able to perform matching based on a bitwise  
> comparison of the entire DN in ID to its entry in the SPD. However,  
> operational experience has shown that using the entire DN in local  
> configuration is difficult, especially in large-scale deployments.  
> Therefore, implementations also MUST be able to perform SPD matches  
> of any combination of one or more of the C, CN, O, OU attributes  
> within Subject DN in the ID to the same in the SPD."
>
> combination of one or more of the C, CN, O, OU attributes? It seems  
> that only implementing the second MUST would be sufficient. If the  
> ID matches a bitwise comparison of the entire DN it will also match  
> a combination of one or more of the C, CN, O, OU attributes.
>
>
> Dave Wierbowski
>
>
Hi Dave.

The difference here is not between IKEv1 and IKEv2, but with the  
difference between the two versions of IPsec, as in RFC 2401 vs 4301.

RFC 4301 did a far better job of specifying the relationship between  
PAD entries and the IKE IDs, so it was not necessary for RFC 4945 to  
specify this.

Section 4.4.3 discusses this thoroughly, especially this paragraph  
from 4.4.3.2:

    This document does not require that the IKE ID asserted by a peer be
    syntactically related to a specific field in an end entity
    certificate that is employed to authenticate the identity of that
    peer.  However, it often will be appropriate to impose such a
    requirement, e.g., when a single entry represents a set of peers  
each
    of whom may have a distinct SPD entry.  Thus, implementations MUST
    provide a means for an administrator to require a match between an
    asserted IKE ID and the subject name or subject alt name in a
    certificate.  The former is applicable to IKE IDs expressed as
    distinguished names; the latter is appropriate for DNS names, RFC  
822
    e-mail addresses, and IP addresses.

So it looks like RFC 4301 has pretty much said this already.

---

From: David Wierbowski <[email-masked]>
Date: Thu, 17 Sep 2009 16:48:05 -0400

Yoav (and also Raj),

Thanks for the clarification.  The text in 4301 makes sense.  What I do not
agree with is the text in 4945 that requires implementations MUST be able
to perform matching based on a bitwise comparison of the entire DN in ID to
its entry in the SPD.  I can agree with saying that implementations MUST be
able to perform matching of the entire DN in ID to its entry in the SPD.
It's the "based on a bitwise comparison" that I do not agree with.  It
should be up to the implementation to decide if it wants to do a bitwise
match or use normal x.500 DN matching rules.

It's certainly not an interoperability issue if I decide to use  x.500 DN
matching rules to do the lookup.  Anything that's a binary match will be a
match using x.500 DN matching rules.  There's no security issue using x500
matching rules.

Since we aren't doing a revision of RFC 4945 it's a moot point.  If we ever
do re-spin 4945 then it's a requirement that I think could be relaxed.

Dave Wierbowski

z/OS Comm Server Developer

 Phone:
    Tie line:   620-4055
    External:  607-429-4055

  From:       Yoav Nir <[email-masked]>                                                                                    
                                                                                                                                
  To:         David Wierbowski/Endicott/IBM@IBMUS                                                                               
                                                                                                                                
  Cc:         "[email-masked]" <[email-masked]>                                                                                 
                                                                                                                                
  Date:       09/17/2009 02:50 AM                                                                                               
                                                                                                                                
  Subject:    Re: [IPsec] Populating ID_DER_ASN1_DN                                                                             
                                                                                                                                
  Sent by:    [email-masked]                                                                                            

Hi Dave.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 18 Sep 2009 00:36:09 +0300

By the time we re-spin RFC 4945, and I'm not saying that we will, it will look silly specifying stuff for IKEv1, so that section will probably be omitted.

On Sep 17, 2009, at 11:48 PM, David Wierbowski wrote:

Yoav (and also Raj),

Thanks for the clarification. The text in 4301 makes sense. What I do not agree with is the text in 4945 that requires implementations MUST be able to perform matching based on a bitwise comparison of the entire DN in ID to its entry in the SPD. I can agree with saying that implementations MUST be able to perform matching of the entire DN in ID to its entry in the SPD. It's the "based on a bitwise comparison" that I do not agree with. It should be up to the implementation to decide if it wants to do a bitwise match or use normal x.500 DN matching rules.

It's certainly not an interoperability issue if I decide to use x.500 DN matching rules to do the lookup. Anything that's a binary match will be a match using x.500 DN matching rules. There's no security issue using x500 matching rules.

Since we aren't doing a revision of RFC 4945 it's a moot point. If we ever do re-spin 4945 then it's a requirement that I think could be relaxed.

Dave Wierbowski

Phone:
Tie line: 620-4055
External: 607-429-4055

Yoav Nir ---09/17/2009 02:50:34 AM---On Sep 17, 2009, at 5:33 AM, David Wierbowski wrote: > Section 3.1.5 of RFC 4945 states that when ge

From:   
Yoav Nir <[email-masked]<mailto:[email-masked]>>
To:     
David Wierbowski/Endicott/IBM@IBMUS
Cc:     
"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date:   
09/17/2009 02:50 AM
Subject:        
Re: [IPsec] Populating ID_DER_ASN1_DN
Sent by:        
[email-masked]<mailto:[email-masked]>

________________________________

Hi Dave.

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 18 Sep 2009 11:57:22 +0300

> match or use normal x.500 DN matching rules.

I think one of the reasons the bitwise comparison is there, that some
CA products have been known to issue certificates which are invalid by
normal processing rules, for example they can use characters that are
not allowed for PRINTABLE STRINGS (for example Latin1 characters for
names). Depending on your matching engine it might be impossible to
get those matching without bitwise comparison. 

I agree that it being MUST is not needed, it could be MAY or SHOULD.
-- 
[email-masked]