Subject: RE: X.509 ACs vs. SPKI?

From: "Fillingham, David W." <[email-masked]>
Date: Thu, 27 May 1999 11:08:53 -0400

All:

One question I've had along these lines is why is it that people are
generally perfectly willing to accept the binding of a name authenticated
via an X.509 certificate for authenticating access via access control lists,
but believe the same approach to be unsecure for authenticating access via
attribute certificates?

In other words, building access control lists that bind attributes to
Distinguished Names, then controlling access based on comparing the
Distinguished Name of the subscriber (based on an X.509 certificate-based
authentication) against the Distinguished Name in the list is, I think,
considered to be a pretty strong security mechanism.

But controlling access based on comparing the Distinguished Name of the
subscriber (based on an X.509 certificate-based authentication) against the
Distinguished Name in an Attribute Certificate is considered to be a pretty
weak security mechanism.

It just seems to me that in either case, the strength or the weakness of
using DNs to bind identities to attributes is determined by the strength of
the binding between names and identities provided by the X.509 certificate,
which is based on which CAs are being relied upon, their Certificate
Policies, and the mechanisms used to validate the certificates.

But I may be missing something important that someone else could point out
to me.

Dave

> ----------
> From: 	Stephen Kent[SMTP:[email-masked]]
> Sent: 	Thursday, May 27, 1999 10:12 AM
> To: 	Denis Pinkas
> Cc: 	[email-masked]; [email-masked]
> Subject: 	Re: X.509 ACs vs. SPKI?
> 
> Denis,
> 
> Yes, there is a problem with tying an AC so closely to a key, or even to a
> cert in its entity, as Russ pointed out to me in a private message.  One
> can imagine a spectrum of binding, from the subject name to the public key
> hash, to a hash of the whole cert.  The tighter the binding, the less
> opportunity for confusion or for malicious rebinding. Tighter bindings may
> require duplicate ACs, as in the examples you and Russ provided, and more
> frequent reissuance, based on identity cert reissuance.  However, I am
> very
> concerned about security lapses here, so we will need to carefully
> evaluate
> the benefits and costs of different approaches to effecting the binding.
> Issuing additional ACs because of a key hash or cert hash binding may not
> be so bad.  Still, I may have overstated the need to use these hashes in
> all cases in ourt profile.
> 
> Steve
>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 27 May 1999 11:34:36 -0400

Dave,

Good point.  One really needs to check the name from an identity cert in
context, e.g., after making sure that the whole cert chain is acceptable
for the context in question.  if we made more use of nameConstraints, this
would be easier to manage and less error/attack prone.  I suspect that part
of the alarm cited here arises from a concern that imeplementations of
access controllers will fail to impose the necessary constrain checks and
thus will open up new avenues of attack.  For example, say you receive an
attribute cert and identity cert from a user. The module for identity cert
validation is invoked and it returns OK, because the user in question is
authorized to do something in your system.  However, the attribute cert was
really bound to another user with the same subject name, due to inadeqaute
controls over name spaces, or due to malicious behavior on the part of a CA
in some other administrative domain.  The result might be a granting of
inappropriate access to the user.  While it is true that the same thing
could happen based solely upon subject name mismanagement, the
opportunities for these sorts of errors may be even greater when we add the
additional complexity of processing ACs.  I won't claim that this is an
airtight argument, but I think it captures the flavor of the concerns that
motivate soem fo the discussion you are seeing on the list.

Steve