Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets andProxies

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 10 Oct 2000 12:13:42 -0600

There is nothing like wide-eyed child saying "Mommy, mommy, the Emperor doesn't have any clothes on!" to make the grown-ups wake up and take notice.  (No offense intended, Polar!)

But let me clear up a couple of possible misunderstandings.  In one message, Polar said that George#2 "steals" the attribute cert of George#1. I assume that by that he meant something like Al Arsenault's scenario, whereby George#2 gets a deliberately confusing certificate from a rogue CA, i.e., he did not simply steal George#1's private key.  I assume Polar understands, but I want to be sure.

Second, it should be obvious that the chain of trust from the root-level Attribute CA is every bit as important as the chain of trust involved in the identity CA chain.  If you don't trust the root, and every subordinate CA in the chain, with respect to some policy then you can hardly expect to trust the end-entity.  Unfortunately, adding more and more "trusted roots" to the various browsers and other relying party software makes the security weaker, not stronger -- a fact that the end users and some important vendors don't seem to have grasped yet.

But assuming that the Attribute CA's are credible, then the possibility of a collision in the issue name and serial number name space seems somewhat improbable, but not at all impossible.  In fact, an attacker could conceivably request certificates one at a time until a serial number collision did occur. Likewise, the DN name space could also collide. Maybe less likely in the case of someone named Jueneman or Arsenault, but highly likely in the case of a "Smith".

I'll confess that I have almost completely ignored the attribute certificate standards progression, because I am not yet sufficiently convinced as to the business case for such certificates to spend much time on them.

But I have to say that this seems like one case where our colleagues in the (moribund?) SPKI group may have a very valid point.  The connection between the attribute cert and the identity cert should not be based on the name, nor on the issuer/serial, but on the KEY contained in the identity cert, or better yet on a message digest of the entire referenced certificate.  

Assuming that is what the Object Digest represents, and based solely on my imperfect level of understanding, it seems to me that the DN and/or issuer/serial number relationship might be useful hints in trying to tack down the identity cert, but that the match MUST be based on an object digest of the entire certificate which is incorporated by reference.

Isn't that why digital signatures were invented, so we could validate more than just the name of a document, but actually validate the content?

Bob

>>> Al Arsenault <[email-masked]> 10/10/00 09:10AM >>>
Okay, I think I finally figured out what Polar is getting at here, but
I'm not sure what the fix is.  Let me try to illustrate with an example. 

(We'll be picking on Stephen a little bit in this; nothing personal
intended; apologies for any offense.  :-)

Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
Technologies, OU=Public CAs, CN=The CA". 
That CA has a self signed certificate with subject and issuer both equal
to the DN above.

Now, there is an end-user certificate issued under that CA.  The issuer
field of that certificate will be the DN above; the subject field is
"C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
CN=Stephen".

The serial number field will be something like "4434".

Now, an attribute authority has issued our friend Stephen an AC
consistent with the proposed profile.  The "Holder" field in that AC can
be one of three things, according to the proposed profile:

	- it can be the issuer and serial number of the base PKC; that is
"C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"

	- it can be the entity name, which by the I-D MUST be "C=IE,
O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"

	- it can be an ObjectDigest - for which the I-D does not require
support.

Okay, that's the legitimate setup.  Now, Awful Al the Attacker wants to
claim Stephen's legitimate AC as his own. So, he can set up his own CA
and issue a self-signed certificate with the same name as the legitimate
one, that is "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The
CA".  The KEY cannot be the same - we'll assume that the attacker
doesn't know the root CA's private key, which is usually a reasonable
assumption - but you can't stop the attacker from copying the names.
Then, Al can use that certificate to issue a user certificate with the
same DN as Stephen's, namely "C=IE, O=Baltimore Technologies, OU=Public
CAs, OU=Architects, CN=Stephen".  The serial number of this certificate
will be "4434", just like in the legitimate certificate.

Now, the question is, given the value of the "Holder" field in the AC,
to which PKC does it correspond - Stephen's real one, or Al's forgery?
Based on the Issuer/serial number option, you can't tell - both
purported certs have identical issuer and serial number values. Based on
the entityName option, you also can't tell - even though you've used the
full DNs, they're identical; it's just the keys (and signature values,
of course) that are different. Based on a Digest of the PKC or PK, you
could tell.

Now - how realistic is this attack in practice? I don't know.  First of
all, I as the attacker could simply fake an AC issuer's cert first,
rather than start from the root CA.  Second, so what if I have managed
to convince somebody that an AC goes with my PKC vice Stephen's - has it
gained me anything useful?  I'm not sure. Third, this attack starts by
exploiting the age-old issue with PKCs that you have to get the root
CA's public key through some secure, out of band means in order to make
everything work.

So I'm not sure what the solution to this is, other than reversing
ourselves and mandating the ObjectDigest choice.  It's clearly not
"include the entire DN vice just the CN". At this point, I think that
the easiest thing to do may be to strengthen the warning in the Security
Considerations section.  That is, explain this issue and that it may be
a risk in some environments.  I don't think that we want to make any
other changes at this point.

(If Stephen and Russ agree on that approach, I can propose a paragraph
or two for the Security Considerations section. Otherwise, I'm at a loss
for a solution.)

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.

Polar Humenn wrote:
> 
> On Sun, 8 Oct 2000, Stephen Farrell wrote:
> 
> >
> > Hi,
> >
> > As I've said to Polar previously, I don't see what issue he's raising and
> > if it is an issue then it also applies to public key certificates (I think
> > this is more or less what Carlisle was saying is a previous response to the
> > PKIX list).
> 
> As I have said before. I do not have a problem with PK certificates
> because they are usually accompanied by *Verifying* certificates. Even if
> you only get one public key certificate for a subject say from a client
> program, you must *have* the issuer's certificate to verify it.
> 
> For a contrived example, say you may could have two different issuer PKCs
> with the same DN. Only one of those certificates will verify the subject's
> certificate. That argument recursively completes the naming path to its
> root.
> 
> With the AttributeCertificate it is different, because you only name the
> "Holder", and not the path from its root, which is indeed its entire name.
> In the attribute certificate there is no "Holder" certificate that can be
> verified. There is no other evidence tying the holder to its issuer
> completing its name. Therefore, there is abolutely no definiative way to
> complete its entire name. Even if you use the Issuer-Serial form, the name
> of the Issuer has the same problem. The only time that works is when the
> issuer of the holder's identity is a root CA. The issuer of the holder's
> identity might be a CA other than a root CA.
> 
> In simplistic terms, With PKCs it's like saying:
> 
> "This is George Burns."
> 
> And with an Attribute Certificate, it's like saying:
> 
> "George has Cigars"
> 
> If you have a PKC that says
> 
> "This is George Bush"
> 
> Which George has the cigars?
> 
> Cheers,
> -Polar
> 
> > Acrtually, maybe this is clearly shown from Polar's suggestion that the
> > "fix" is to change the definition of GeneralName (and hence the base
> > X.509-2000 and rfc2459 as well as the AC profile).
> >
> > Maybe its me - can anyone else see the issue?
> >
> > Regards,
> > Stephen.
> >
> > Patrik Fältström wrote:
> > >
> > > This should be discussed on the PKIX mailing list.
> > >
> > > Please discuss...
> > >
> > >      Patrik Fältström, Area Director Applications Area, IETF
> > >
> > > >Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
> > > >From: Polar Humenn <[email-masked]>
> > > >To: [email-masked] 
> > > >Subject: AttributeCertificates: Path Names to AC Holders, Targets and Proxies
> > > >
> > > >
> > > >
> > > >Greetings IETF,
> > > >
> > > >This is Polar Humenn with the Object Management Group (OMG).
> > > >
> > > >I have some questions about total interoperability about the PKIX
> > > >Attribute Certificate when used in environments where your application
> > > >does not have control over both clients and server, i.e. they both don't
> > > >subscribe to the same LDAP server.
> > > >
> > > >I have some problems regarding the use of GeneralName for the Holder,
> > > >Proxies and Targets fields of the AttributeCertificate.
> > > >
> > > >When using DN's for these names, they only specify one level of naming.
> > > >That is, they do not specify the Identity Chain, (i.e. path) upto a
> > > >certain authority. Specifically, they do not name the Holder's CA, and its
> > > >CA, and so on.
> > > >
> > > >Even using the Issuer-Serial type of GeneralName is not good enough to
> > > >identify a holder, proxy, or target of the Attribute Certificate because
> > > >it has the same problem in identifying the issuer.
> > > >
> > > >Let me illustrate a security hole that this specification has:
> > > >
> > > >Let's say I am a CA that defines employee identities. I'm pretty low on
> > > >the totem pole, because of my organizational structure. My identity
> > > >certificate has a path from a real trusted authority, such as:
> > > >
> > > >1. CN=Baltimore
> > > >2. CN=General Motors
> > > >3. CN=Manufacturing
> > > >4. CN=Engineering, L=Germany
> > > >5. CN=Human Resources
> > > >
> > > >All my employee identities are defined by 5 and their certificates are
> > > >signed by 5's public key. Here's one of my employees and his certificate
> > > >serial number:
> > > >
> > > >6. CN=Henry Ford      Serial#=1234
> > > >
> > > >I obviously listed the chain with 1 as the most significant. For example,
> > > >if Henry authenticates via TLS, he delivers a chain of these 6
> > > >certificates.
> > > >
> > > >And now for something completely different, let's switch to Holden Car
> > > >Company, Australia.
> > > >
> > > >The privilege service that Holden subscribes to wants to issue a attribute
> > > >certificate to Henry Ford from General Motors so that he can access the
> > > >Holden plant through the Internet. It is clearly not enough that I just
> > > >define the "Holder" as using the Issuer-Serial form of GeneralName, such
> > > >as:
> > > >
> > > >CN=Human Resources
> > > >Serial#=1234
> > > >
> > > >I really have to fully define the path of the holder so that we can verify
> > > >that the attribute certificate actually applies to the identity I am
> > > >presented with.
> > > >
> > > >For a contrived example, let's say the GM has authenticated a client using
> > > >SSL, and the plant has Versign's verification certificate (i.e.
> > > >CN=Verisign). The authentication provides me with the following cert
> > > >chain, which the GM plant has verified:
> > > >
> > > >1. CN=Verisign
> > > >2. CN=Holden
> > > >3. CN=Human Resources
> > > >4. CN=Ian Botham, Serial#=1234
> > > >
> > > >Then he delivers to the plant the Attribute Certificate for Henry Ford.
> > > >
> > > >Does it match? Yes, it sure does.
> > > >Should this happen? Obviously not.
> > > >
> > > >I know it's a bit contrived, but it is a security hole.
> > > >
> > > >Now, if the Holder contained the name path to that serial number, then
> > > >there wouldn't even be a question of whether the AC applied to Ian Botham
> > > >or not.  (Provided both the privilege service and target both trust the
> > > >same named high-level certificates, such as Verisign or Baltimore for
> > > >verification).
> > > >
> > > >The same goes for the naming of the targets and proxies.
> > > >
> > > >The problem exists for regular DN naming as their may be two CN=Henry
> > > >Fords at both GM and Holden.
> > > >
> > > >What can we do about this problem?
> > > >
> > > >I would suggest either changing the definition of GeneralName to include
> > > >DN paths. Alternatively, I may suggest attribute extensions (critical or
> > > >non-critical?) that complete the path from the Holder, proxies, or
> > > >targets.
> > > >
> > > >I do not have a problem with the Issuer of the Attribute Certificate,
> > > >because that will be followed by some verifying PK certificates, which
> > > >consequently defines the issuers name path.
> > > >
> > > >Any comments?
> > > >
> > > >Cheers and Thanks,
> > > >-Polar
> > > >
> > > >-------------------------------------------------------------------
> > > >Polar Humenn                  Adiron, LLC
> > > >mailto:[email-masked]       2-212 CST
> > > >Phone: 315-443-3171           Syracuse, NY 13244-4100
> > > >Fax:   315-443-4745           http://www.adiron.com 
> >
> > --
> > ____________________________________________________________
> > Stephen Farrell
> > Baltimore Technologies,   tel: (direct line) +353 1 647 7406
> > 61 Fitzwilliam Lane,                    fax: +353 1 647 7499
> > Dublin 2.                mailto:[email-masked] 
> > Ireland                             http://www.baltimore.com 
> >
> 
> -------------------------------------------------------------------
> Polar Humenn                  Adiron, LLC
> mailto:[email-masked]       2-212 CST
> Phone: 315-443-3171           Syracuse, NY 13244-4100
> Fax:   315-443-4745           http://www.adiron.com

---

From: Polar Humenn <[email-masked]>
Date: Tue, 10 Oct 2000 16:11:09 -0400 (EDT)

On Tue, 10 Oct 2000, Bob Jueneman wrote:

> There is nothing like wide-eyed child saying "Mommy, mommy, the
> Emperor doesn't have any clothes on!" to make the grown-ups wake up
> and take notice.  (No offense intended, Polar!)

No offense taken. :)

> But let me clear up a couple of possible misunderstandings.  In one
> message, Polar said that George#2 "steals" the attribute cert of
> George#1. I assume that by that he meant something like Al Arsenault's
> scenario, whereby George#2 gets a deliberately confusing certificate
> from a rogue CA, i.e., he did not simply steal George#1's private key.  
> I assume Polar understands, but I want to be sure.

Correct. I assume no public keys are stolen. The PKI is intact.

> Second, it should be obvious that the chain of trust from the
> root-level Attribute CA is every bit as important as the chain of
> trust involved in the identity CA chain.  If you don't trust the root,
> and every subordinate CA in the chain, with respect to some policy
> then you can hardly expect to trust the end-entity.  Unfortunately,
> adding more and more "trusted roots" to the various browsers and other
> relying party software makes the security weaker, not stronger -- a
> fact that the end users and some important vendors don't seem to have
> grasped yet.

Yep. I assume that there is a chain of Public Key Certificates verifying
the issuance of the attribute certificate, just like any PKCA issues
Public Key Certificates.

> But assuming that the Attribute CA's are credible, then the
> possibility of a collision in the issue name and serial number name
> space seems somewhat improbable, but not at all impossible.  In fact,
> an attacker could conceivably request certificates one at a time until
> a serial number collision did occur. Likewise, the DN name space could
> also collide. Maybe less likely in the case of someone named Jueneman
> or Arsenault, but highly likely in the case of a "Smith".

I agree.

> I'll confess that I have almost completely ignored the attribute
> certificate standards progression, because I am not yet sufficiently
> convinced as to the business case for such certificates to spend much
> time on them.
> 
> But I have to say that this seems like one case where our colleagues
> in the (moribund?) SPKI group may have a very valid point.  The
> connection between the attribute cert and the identity cert should not
> be based on the name, nor on the issuer/serial, but on the KEY
> contained in the identity cert, or better yet on a message digest of
> the entire referenced certificate.

Exactly.

> Assuming that is what the Object Digest represents, and based solely
> on my imperfect level of understanding, it seems to me that the DN
> and/or issuer/serial number relationship might be useful hints in
> trying to tack down the identity cert, but that the match MUST be
> based on an object digest of the entire certificate which is
> incorporated by reference.
>
> Isn't that why digital signatures were invented, so we could validate
> more than just the name of a document, but actually validate the
> content?

Exactly. At this point I think the ObjectDigest form of the Holder should
be mandated. Let there be a critical attribute extension that can be used
to locate the Holder's identity certificate. The question is should it's
existance be mandatory.

You need at least a DN path to a CA that you trust. The problem with
interoperability on a wide scale is that the AA probably needs to specify
the DN path all the way up to the Root CA of the Holder for which
privileges are requested.

Any other suggestions?

Cheers,
-Polar

---

From: Stephen Kent <[email-masked]>
Date: Tue, 10 Oct 2000 21:30:14 -0400

Bob,

One could choose to mandate an AC binding to the subject's public key 
or the whole cert, rather than to a name, but that causes the 
undesirable effect of mating the AC's validity to the base cert 
validity.  ACs have chosen to not require such a binding, although to 
allow it as an option, preferring instead to allow a more general 
binding, which has attendant security concerns. SPKI chose one of the 
three options ACs offer, which has security benefits, but also 
management problems.

Steve

---

From: Camillo Särs <[email-masked]>
Date: Wed, 11 Oct 2000 10:54:43 +0300

Bob Jueneman wrote:
> But I have to say that this seems like one case where our colleagues in 
> the (moribund?) SPKI group may have a very valid point.  The connection 
> between the attribute cert and the identity cert should not be based on 
> the name, nor on the issuer/serial, but on the KEY contained in the 
> identity cert, or better yet on a message digest of the entire > referenced certificate.

Actually, there is no need to be that strict.  Correct me if I'm wrong, but
the underlying problem here is name space collisions.  I.e. the CA and AA
name spaces may overlap, leading to problems in interpreting names.  The
SPKI group also recognized the need for name certificates, as a tool for
indirection and grouping, but the SPKI name spaces are always locally
defined and rooted in a public key.  No assumption on global names are
present.

One of the proposed solutions here required the trusted CA and AA name
spaces to be "reasonable".  With the rapid increase in available TTP CA
certificates, I feel this assumption is insecure.  If Attribute Certs are
to be generally applicable, we must base their security on some other
property.

My opinion is that using the Object Digest would unnecessarily bind the
Attribute Cert to the actual issued Identity Cert.  If the digest would
only be over the key, the usefulness of the DN would be removed.  If the
cert would be referenced, the Attribute Cert validity period would be
limited by that of the Identity Cert (as in SPKI).

A useful solution to this problem would tie the Attribute Cert to the
issuing entity that issued the Identity Cert in an unambiguous fashion. 
I.e. the Attribute Cert must identify not only the DN, but a relevant
trusted root CA.  Is this requirement too strict?

Regards,
Camillo
-- 
Camillo Särs <[email-masked]>       http://www.iki.fi/ged/
Researcher, F-Secure Corporation               http://www.F-Secure.com

   F-Secure products: Securing the Mobile, Distributed Enterprise