Subject: Comments on draft-ietf-pkix-ac509prof-05.txt

From: Polar Humenn <[email-masked]>
Date: Thu, 12 Oct 2000 15:21:55 -0400 (EDT)

This message is from Polar Humenn from Adiron, LLC; Syracuse University;
and the Object Management Group(OMG) Security SIG.

Greetings IETF, PKIX WG, OMG Security SIG, and OMG E-Commerce DTF:

I have analyzed the X.509 Attribute Certificate Draft Specification and
have come to the conclusion that a glaring problem exists. The problem
relates to the verification that the Relying Party(RP) carries out on the
Attribute Certificate(AC) issued by an Attribute Authority(AA) for a
particular subject entity. This problem exists in the case when the
subject entity is represented by a chain of Public Key Certificates (PKC),
such as in, but not limited to, SSL or TLS.

I also state a recommendation of the creation and use of the AC's in their
current form, draft-ietf-pkix-ac509prof-05.txt, for systems in which
verification of that AC belongs to particular subject entity is paramount.

The Problem:

Only the least significant part of the AC's Holder's Identity is present
in the AC.

This anomally is a problem, because it allows impostors or coincidental
bystanders to reap the privileges certified in the AC.

Several Certificate Authorities(CA) may create subject entities with any
DN they choose. An ATTACK may be levied against an RP by virtue of knowing
(or sniffing) the fact that an AC was issued in a particular Holder's DN.
The only prevention against such an attack is that the AA and the RP agree
on common trust points (trusted CA) for verification of the PKCs used to
reference the Holder at the AA, and authenticate the Holder at the RP.
Also the Holder's certificate chain length MUST be no greater than 2 and
that the DN spaces underneath each trusted CA the AA and RP agree on MUST
be distinct.

On The Distinctness of DN space:

In the following treatise, DN's are represented by single words, such as
CA1 and DN1. A DN path from most significant to least significant is
represented as DNs separated by colons (:), such as CA1:DN1. 

In the case where CA1 and CA2 are Certificate Authorities and they certify
names in a common DN space, name collisions can exist. [Note: There is no
mandate that either CA1 or CA2 know anything about each others name
spaces]. 

The problem is that if the AA certifies privileges for CA1:DN1, only DN1
goes in the AC. If the RP gets an authentication from CA2:DN1 (which is a
different subject entity). The AC WRONGFULLY applies. The AA did NOT issue
CA2:DN1 the privileges, it issued them to CA1:DN1.

The structure of DN's will NOT solve this problem, since there is no
mandated relationship between an Issuer's DN and a Subject's DN in a
Public Key Certificate. i.e. there is no relationship between the internal
structure of CA1 and the internal structure of DN1. Therefore, no
implication can be made as to the Holder's Issuer's name from the Holder's
DN alone.

This problem is tantamount considering 1234 and 3214 equal numbers. This
problem is also tantamount to ordering and paying for a pizza under credit
card 2132 2323 3343 3433 and letting anybody with a credit card xxxx xxxx
xxxx 3433 pick it up.

This situation DOES NOT lend itself to a GOOD E-commerce model.

It is also said that the following scenario is desirable and should be
supported:

The following scenario is attributed to Stephen Farrell from an email I
received from him:

> CA1 certifies holder.
> CA2 certifies CA1.
> AA trusts CA2 as a "root"
> CA3 also certifies CA1.
> RP trusts CA3 as a "root"

> Both [CA2,CA2],[CA2,CA1],[CA1,holder] and
> [CA3,CA3],[CA3,CA1],[CA1,holder] are potentially valid paths, where
> [x,y] means "x certifies y". Based on their respective configurations
> the first path is usable by the AA, the second by the RP.

In this case, the RP has no idea what the AA certified. Does
CA2:CA1:Holder really the same as CA3:CA1:Holder?

The RP would have to know that some cross certification is possible, i.e.
that actually AA was using CA2:CA1 for referencing Holder. This is
impossible and cannot be verified unless the RP has intimate knowledge of
the AA.

Using the baseCertificateID IssuerSerial form of the Holder in the AC:

Using the baseCertificateID IssuerSerial form of the AC Holder just pushes
the problem up one level because the Issuer is only named by a single DN,
and not a path from its root CA. If it is NOT the case that the Issuer is
a common trust point for the AA and the RP and they agree that the DN
references the same certificate, verification of the AC with respect to
the Holder's certificate serial number cannot even be performed.

If the Holder is defined by a CA that is two levels deep, verification of
the AC with respect to the Holder certificate serial number cannot be
performed. Attacks can now be enumerated by creating certificate chains
with bogus PKCs with serial numbers and the Issuer's DN.

Widely Scaled E-COMMERCE Model:

This model for E-COMMERCE should be able to be supported by an AA and RP.

The RP sells Pizza. 
A user labeled by a PKC chain of RootCA1:CA2:Batman wants to buy a pizza.
He contacts the RP's AA, pays for the pizza, and the AA creates an AC with
attributes telling the RP that a pizza has been purchased.

Note that this can be an pseudo anonymous process. In this process, the AA
authenticates Batman all the way up to the RootCA1. It is not the job of
the AA to care if the RootCA1 is a trusted entity of the AA. The AA for
the purposes of collecting money trusts all Root CA's only for the purpose
of authentication. There is just an agreement between the AA and the RP
that whatever identity certificate chain is presented to the AA, verifies
to a root. The AA and RP don't care who it is or who certified it, just
that the entity paid for a pizza, AND that the same entity that paid for
the pizza walks out with the pizza.

Unfortunately, the standard X.509 AC only contains the Holder as "Batman".

RootCA1:CA2:Batman authenticates to the RP to pick up a pizza. The AC
(either delivered by Batman, or gotten from some directory) verifies in
this case and Batman gets his pizza.

ALSO: 

If RootCA2:CA43:CA33:Batman authenticates to the RP and orders a pizza,
without going to the AA first. The AC verifies and he, THE WRONG BATMAN,
gets a pizza.

This is tantamount to a standard college prank, of which this Attribute
Certificate Model as it stands, cannot prevent.

For this scenario to work without common trusted CA certificates between
the AA and RP, the AC needs to contain the entire DN path from the RootCA
to the Holder, AND it MUST contain a hash of the Holder's RootCA
certificate to prove that the same certificate chain presented to the AA
was presented to the RP.

Recommendation for Verifiability of the X.509 AC:

Aside from HIGHLY CONSTRAINED environments, where agreements between AAs
and RPs go down into intimate details, there is only one Profile that can
breed VERIFIABLE trust that the AA actually certified the subject entity
the RP is dealing with:

Verifiable Profile;
1. The AA MUST use the baseCertificateID IssuerSerial form of the Holder.
2. The AA and RP must agree that ANY Issuer Name in the 
   baseCertificateID field resolves to the SAME certificate 
   in their respective repositories,i.e. Common Trust Points. 
   That is, any verification chain of a Holder's PKC cannot
   be greater than 1 from any trust point common to both the AA and the
   RP.
3. The RP MUST reject any AC for which the AA and RP have not 
   emphatically agreed on to be a common trust point, even if
   the RP can locate the Issuer's certificate via the DN in the
   baseCertificateID field of the AC.

This solution does not scale well. The AA and RP must communicate
agreements on common trust points.

Requirement 1 is unfortunate because that may require a lookup at the RP
and keep and it definitely ties the AC to the subject entity's
certificate. This effect is undesirable especially in the case of key
rollover, where a new PKC with a different serial number is issued.

The reliance on common trust points severely limits the use of the AC in
widely scaled environments.

Recommendation to the OMG, Security SIG, and E-Commerce Groups;

The OMG Security Protocol (CSIv2) has stated that the IETF AC X.509
Profile be used for it's delivery of privilege information. I only can
recommend that the above Recommendation for Verifiability be followed for
CORBA and EJB systems that use X.509AC, or that the OMG Security Group
fashions its own X.509 Profile with new attribute extensions solving the
problem of verification of X.509 AC, or it creates a new privilege
certificate altogether.

Sincerely,
Polar Humenn

-------------------------------------------------------------------
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: Thu, 12 Oct 2000 22:12:32 +0100

Polar,

Since you choose to quote from that off-list mail, let me complete the
quote somewhat:

You wrote:

> > Help me out here. This one I don't understand? How can another path exist?
> > The PKIXPROF mandates that the Issuer field of a PKC MUST match a subject
> > field of the certificate containing the public key that verifies it. That
> > really mandates just one path up to the RootCA for the holder's identity.
> > How can a different path exist?

And I responded:
 
> Both [CA2,CA2],[CA2,CA1],[CA1,holder] and [CA3,CA3],[CA3,CA1],[CA1,holder]
> are potentially valid paths, where [x,y] means "x certifies y". Based on their 
> respective configurations the first path is usable by the AA, the second by 
> the RP.

The bottom line seems to be that you have a different concept of "identity" 
to that which has been understood in PKIX for the last five years. Your 
concept of "identity" is the entire sequence of DNs from the end-entity 
PKC subject field, up to a "root" CA, including all CA names in between. 
PKIX treats the end entity PKC subject field by itself as an identity
(and no, I don't want to start another of those interesting discussions
about whether this is good or bad!).

I can only guess that this is ultimately why you percieve there to be such 
a problem, where others don't. 

So, can we leave it there and agree to disagree as to what consitutes
an "identity"? (I'd *much* rather that than to have to parse & respond 
to all of your "treatise":-)

Stephen.

PS: Can we also drop the huge cc list if there are any more mails on 
this topic? The AC profile is a PKIX draft - whoever's interested can
discuss it there.

-- 
____________________________________________________________
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: Thu, 12 Oct 2000 19:09:46 -0400 (EDT)

Stephen,

Comments below:

> > respective configurations the first path is usable by the AA, the second by 

Yes, and thank you for clearing up my confusion. And from your response, I
should note, that I concluded the problem was worse than I had originally
imagined. :)

> PKIX treats the end entity PKC subject field by itself as an identity

Which means that the DN MUST be globally unique? Is the fact that a single
DN is just NOT empahtiacally guaranteed to point to a unique subject
entity just specifically avoided in arguments for the sake of
functionality, which in this case is *security functionality*?

> about whether this is good or bad!).

Right. We should not be concerned about about the integrity of such an
infrastructure. We should just use what is given to us, whether it is good
or bad. ;^)

And I guess, why not? I have a machine (of which I only use when forced
to) on my desk with an operating system made by a popular software company
that just can't get out of its own way and stop crashing, getting
diseases, etc. I have to use it sometimes because everybody else uses the
same thing and sends me stuff only it can understand. Oh well. I should
just accept this. Okay. It's a market. It's a standard. :)

> I can only guess that this is ultimately why you perceive there to be such 

Your "guess" is correct! At least you recognize my problem with the entire
thing.

What I would like is an answer to the verifiability problem all the way up
the identity chain of the Holder. The PKIXPROF tells you how to verify a
PKC chain. Why does it even bother walking up a chain? All PKIX identities
and public keys should be signed by Verisign and be done with it. :^)

But seriously, the AC draft says nothing other than that when using the
baseCertificateID it must match that of the components of the
authenticated entity's certificate. It's just not enough in the cases of
PKC chains greater than 2. Even the an Issuer UID can be forged in the
holder's PKC along with the DN and the serial number, especially if I am
allowed to have two CA's certify the same certificate as you have pointed
out above.

I don't mind if a single certificate subject field points to one and only
one unique subject entity.  But I cannot ignore, skip, or gloss over the
fact that the DN is just NOT unique in the PKIX space.

I do like Tom's suggestion of being able to use the subjectAltName in
places where uniqueness is a factor, ignoring the subject DN. The problem
is being able to force vendors of AAs to use it. In some cases, where
authentication services are provided by widely disparate CA services and
vendors, mandating such things from AA service vendors may be impossible.

> So, can we leave it there and agree to disagree as to what constitutes

Okay. Okay. I wrote something you won't read? I'm defenseless against that
approach.

I just have to tell my customers they can't use such standards and
standard products (at least not without proprietary extensions) and they
will have to use something else for widely scaled e-commerce solutions in
the PKI space.

I guess there is a market for a workable, but inadequate, solution now
with really expensive upgrades later on that fix the problems, albeit
after the attacks, or the screw ups.

"How come I can't get my pizza?" 
"I'm sorry Mr. Smith, you already picked it up!"

> this topic? The AC profile is a PKIX draft - whoever is interested can
> discuss it there.

Surely, now that you've seen my point and my problem with it, let's take
it back to PKIX and the OMG lists. The CC list is for the people I know
are interested and aren't on the lists. I took the iesg off the list.
Hopefully, the concerned parties there are subscribed to the pkix list.

Cheers,
-Polar