Subject: Fwd: AttributeCertificates: Path Names to AC Holders, Targets and Proxies

From: Patrik Fältström <[email-masked]>
Date: Sun, 8 Oct 2000 15:42:13 +0200

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

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 08 Oct 2000 22:39:45 +0100

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).

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.

-- 
____________________________________________________________
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

---

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

> this is more or less what Carlisle was saying is a previous response to the

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Oct 2000 15:26:59 +0100

Polar,

> program, you must *have* the issuer's certificate to verify it.

Quoting from the end of 4.2.2:

  "Any protocol conforming to this profile SHOULD specify which AC
   holder option is to be used and how this fits with the supported
   authentication schemes defined in that protocol."

Clearly, possession of an AC is not enough to claim the privileges
contained therein, so authentication is required. If your "vulnerability" 
depends on the relying party not being able to distinguish between 
different AC holders at the authentication stage then I think the 
problem lies outside of the use of ACs and hence doesn't affect this 
profile.

The AC profile only talks about the use of PKCs as an authentication
mechanism (since this is PKIX). The profile says that holder SHOULD use
the baseCertificateID choice. This means your problem amounts to the 
case where a relying party (in PKI terms) trusts two *different* CAs with 
the same name who've issued PKCs with the same serial number where one 
party has intentionally grabbed the other's AC and is claiming its 
privilege. Aside from not being convinced, this leads back to my 
original point that you're talking about a putative problem with that
relying party's PKI, not to do with ACs (e.g. how could it get 
revocation status, how could it figure out who'd signed an email, etc.)

If the RP chooses to trust an AA then effectively it is choosing to
trust that AA's holder field. I'm sure that if and when ACs become
as widespread as PKCs, then concepts like CPS will be elaborated. At
that point your concerns get addressed, not in the profile.

> For a contrived example...

Real examples are more convincing.

> "Holder", and not the path from its root, which is indeed its entire name.
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Every time you write something like that you loose me entirely.

[..."George" omitted...]

Stephen.

---

From: Al Arsenault <[email-masked]>
Date: Tue, 10 Oct 2000 11:10:14 -0400

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.

---

From: "Christopher S. Francis" <[email-masked]>
Date: Tue, 10 Oct 2000 12:52:24 -0400

Al,

I'm new here so forgive me if I'm missing something obvious, but in your
example, doesn't the relying party have an obligation to verify the
signature on the AC using a key that it is confident belongs to the Source
Of Authority (or a key that can be traced back to an approved SOA)?  If the
relying party in your example validates the AC in this way, the forged AC
would fail the signature check.

What am I missing?

Christopher S. Francis
WetStone Technologies, Inc.
935 Main Street, Suite A-1
Safety Harbor, FL   34695
(727) 642-8993
http://www.wetstonetech.com/

-----Original Message-----
From: Al Arsenault [mailto:[email-masked]]
Sent: Tuesday, October 10, 2000 11:10 AM
To: Polar Humenn
Cc: Stephen Farrell; Patrik Fältström; [email-masked];
[email-masked]
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets
andProxies

                        Al Arsenault
                        Chief Security Architect
                        Diversinet Corp.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Oct 2000 16:31:28 +0100

Hi Al,

You've highlighted why this is *not* an AC issue. As you've correctly 
pointed out its a root CA information distribution issue and is addressed 
by rfc2459 and son-of-2459. If I can corrupt a relying party's store of 
root CA information, then I can do *lots* more damage than just try 
steal an existing AC.

If new security considerations belong anywhere then its in son-of-2459,
but that already says:

  "The quality of implementations that process certificates may also
   affect the degree of assurance provided.  The path validation algo-
   rithm described in section 6 relies upon the integrity of the trusted
   CA information, and especially the integrity of the public keys asso-
   ciated with the trusted CAs.  By substituting public keys for which
   an attacker has the private key, an attacker could trick the user
   into accepting false certificates."

I could possibly (just to kill the thread:-) buy including an equivalent 
paragraph in the AC profile, since its no harm in itself, but I don't want 
to start turning the security considerations section of the AC profile 
into a PKI tutorial - if we accepted that logic, then shouldn't the same 
paragraph then be present in all specifications that use PKI? Seems silly 
to me since one of the big reasons for PKIX existing in the first place
is to collect such things in one place.

On balance, I'd expect implementers of the AC profile to be familiar enough 
with PKI to know that root CA information has to be protected and would
prefer not to change the draft. ('Course if there's a consensus to do it,
I'll do it.)

Stephen.

---

From: Polar Humenn <[email-masked]>
Date: Tue, 10 Oct 2000 14:03:39 -0400 (EDT)

Hi Al,

The issue that you point out, is outside the AC. The fact is that you need
a chain of PK certificates to verify the authenticity of the AC is a
Public Key verification issue of a statement. It only implies that the AC
came from an entity that you may or may not trust.

What you imply after that is what we are talking about.

Cheers,
-Polar

---

From: Al Arsenault <[email-masked]>
Date: Tue, 10 Oct 2000 15:01:06 -0400

Christopher,

	If the relying party properly checks both the AC and purported PKC all
the way back to their trusted roots, and the RP has gotten the "right"
public key for the trusted root, then yes, this attack will be detected.

	First, I'll point out that the AC issuer's PK Cert may or may not chain
back to the same trusted root as the PK cert's of the holders to which
it issues certs.  (That is, in my example, the AC issuer's cert may
chain back to "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The
CA", or to a different root.) The I-D is silent on this issue - properly
so, in my opinion.  

	But, that means that just checking the signature on the AC, and then
checking the AC Issuer's chain is not guaranteed to detect the attack.
If the AC Issuer's PK Cert chains back to a different root, also trusted
by the RP, then just doing that part of the check won't reveal the
attack. You have to check the purported PK Cert, too.

	Which is why I pointed out that it's not clear to me how meaningful
this attack is in practice.  If the RP does the whole job, the attack
should not work. If the RP does a lousy job, and just checks the AC and
accepts the purported PKC without checking, there's a problem in the
system. (It's the RP's fault, but there's still a problem in the
system.)  And if the RP finds Awful Al's PK Cert, tries to validate it
and fails and thus rejects the entire transaction without trying
Stephen's PK Cert, there may be a "denial of service" attack - about
which we may or may not care.

				Al Arsenault

---

From: Russ Housley <[email-masked]>
Date: Tue, 10 Oct 2000 15:10:13 -0400

Al:

I do not understand how the attacker's certificate path validates.  The 
self-signed certificate must be trusted.  That trust comes from procedures 
outside of either the PKC spec or the AC spec.

Maybe we need to make the language stronger about validating the PKC before 
using the AC.

Russ

---

From: Polar Humenn <[email-masked]>
Date: Tue, 10 Oct 2000 15:27:52 -0400 (EDT)

Hi Al,

Thanks for seeing the problem. Comments below:

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

I think the ObjectDigest is truly the only way to go. However, it still
has problems. The object that is talked about must be able to be recalled
and identified. Otherwise the Attribute Certificate MUST ALWAYS be
delivered with the Holder's Public Key Certificate.

I don't believe that requiring the delivery of the Holders certificate is
unreasonable. Can something like this be mandated in this profile? I don't
see how. I only see that in specific protocols. Or am I wrong?

> Now - how realistic is this attack in practice? I don't know.  

The "reality" approach is probably not a great way to reason about this
attack. The "reality" of attacks are always exploited in some form sooner
or later. For example, DES is not considered really good any more, as well
as low bit valued public keys. The arguments for them in their time was
the "reality" of the attack. That reason was just the "reality" of
computing power with respect to the time. However, here what we are
talking about is the "reality" of a glaring hole in the logic. It doesn't
take the reality of a lot of computing power to overcome this one.

> 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. 

I try to look at things in a verifiable way. If I have a Henry Ford from
GM and a Henry Ford from Chyrsler and I have an Attribute Certificate
claiming that Henry Ford has some privilegse, I cannot really say to whom
the privileges belong unless I constrain my operating environment such
that I can throw one out, or deem it impossible, i.e. I don't trust
anything from GM.

The constrained environment approach is okay if I'm running a nuclear power
plant. However, it's not good enough I'm running an E-commerce site in
which I want identities defined by thousands of RA/CA's to be issued
privileges to buy stuff or get access to stuff. I just don't have that
control.

We've done some work on the verifiability of trust in the X.509 public
key directory frame work.

See http://caliper.syr.edu/~tkosiyat/Paper/High_Assurance_X509.ps

We would really like to extend this work to attribute certificates as
well, as it facilitates the need for privileges and delegation within the
X.509 framework. However, if we have holes such as this, it will not be
possible.

> 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.

Not quite so. I can provide this attack without knowing or forging any
private keys. I can be a legitimate user with a real public/private
keypair from a CA. All I need is a name "collision" at a lower level.

The mere fact that I can issue privileges to Henry Ford of GM MUST NOT
mean I have also inadvertently issued privileges to Henry Ford of Chrysler
in some other realm.

> other changes at this point.

I think only strengthening the wording is not really enough. That's like
telling people they SHOULD NOT use Username/Password schemes in the clear.
The mere fact that standards exist such as Telnet, FTP, etc, means we
can't get rid of them, and it's really tough to stop it from happening.

> or two for the Security Considerations section. Otherwise, I'm at a
> loss for a solution.)

The start of the solution is mandating the use of ObjectDigest, where a
digest can be verified against the Holder's Public Key or Public Key
Certificate. The question after that is where does one pull the Holder's
cert or public key from, should it not be readily available, i.e. wasn't
delivered with the AttributeCertificate. This would constitute having the
entire DN path to the Holders public key certificate anyway, and using the
ObjectDigest for verification of the identity.

Could we suggest a critical attribute extension that will contain the path
to the ObjectDigest?

Note, the same problem exists for ProxyInfo and TargetInfo attribute
extensions as well.

Cheers,
-Polar

---

From: Polar Humenn <[email-masked]>
Date: Tue, 10 Oct 2000 15:48:24 -0400 (EDT)

On Tue, 10 Oct 2000, Paul Krumviede wrote:

> "The requested URL /~tkosiyat/Paper/High_Assurance_X509.ps was not
found on
> this server."
>
> -paul
>
> --On Tuesday, 10 October, 2000 15:27 -0400 Polar Humenn
<[email-masked]>
> wrote:
>
> > http://caliper.syr.edu/~tkosiyat/Paper/High_Assurance_X509.ps
>
>

Opps Sorry, The corrected URL is

 http://caliper.syr.edu/~tkosiyat/Papers/High_Assurance_X509.ps

Cheers,
-Polar

---

From: J Johnen <[email-masked]>
Date: Tue, 10 Oct 2000 18:22:21 -0700

unsubscribe me from this list, please.

---

From: Russ Housley <[email-masked]>
Date: Wed, 11 Oct 2000 13:50:42 -0400

>see how. I only see that in specific protocols. Or am I wrong?

PKCs bind a public key to an identity.

ACs bind attributes to an identity.

Authentication, which includes validating the PKC certification path and 
having the remote party perform some operation that involves the private 
key associated with the identity.  Without authentication of the identity, 
who cares what attributes are associated with it?

Russ

---

From: Polar Humenn <[email-masked]>
Date: Wed, 11 Oct 2000 15:48:22 -0400 (EDT)

Russ,

> PKCs bind a public key to an identity.

It is true that PKC's bind a public key to an identity, but that identity
is fully qualified by its subject DN, it's issuer DN, it's issuer's
issuer's DN, and so on all the way up to a root CA. This full identity is
all tied together all the way up to the root by chaining of signatures.

> ACs bind attributes to an identity.

The AC's bind attributes only to the least significant component of an
identity, not the entire identity. The rest of it, i.e. he most
significant part, is THROWN AWAY.

> who cares what attributes are associated with it?

True, but in some cases you may infact be removed from the authentication.
Take a case where you have a webserver that uses SSL. The
authentication information of a user is processed on the webserver. Now
the web server may want to access some database server on the
authenticated user's behalf. The web server cannot authenticate as the
user. There are several ways to do this. One way is for the name of the
authenticated entity to be to propagated. So, on the database server, the
name who the webserver is acting on behalf is transmitted to the database
server. The database trusts the webserver in this matter. 

The question is what identifying information is good enough? Add an AC in
there or and AA to pull from, you have to emphatically know what that name
is refering to and if they are the same. A simple DN will not work in the
widely scaled interoperable case.

Cheers,
-Polar