Subject: RE: Comments: An Intranet Attribute Certificate Profile for Autho rization

From: Hal Lockhart <[email-masked]>
Date: Fri, 7 Jul 2000 11:26:10 -0400

Since the responses so far have been negative, let me put in a (partially)
supportive comment.

We are also implementing ACs in an environment where they are passed over a
secure channel. We also are supporting audit id.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]

...

> (1) The draft does not adequately support anonymous 
> operations with audit id.

...

>      The combination of these two requirements implies that 
> there MUST be an
> attribute other
>      than the audit id in an AC.  This makes fully anonymous 
> (but auditable)
> operations very difficult.

I don't really understand this. Anonymous to whom? ACs are no good unless
you bind them to an authenticated identity. Section 4.2.2 requires that if
the authentication is via PKI, they should be bound to the base certificate.
My understanding of RFC 2459 is that there has to be an identity either in
subject name or altname. I recall discussion of explicitly pseudonomous
identifiers, but this was not adopted. Similiarly, most non-PKI
authentication
systems use some kind of username or account to base authorization decisions
on.

It seems to me then that you are trusting the behavior of the process that
consumes the AC and generates the audit record to correctly use the audit id
rather than some traceable identifier. Given that, it seems harmless to have
other crufties (thanks, Peter G.) in the AC.

>      Making audit IDs extensions rather than attributes complicates
> implementation unecessarily
>      in any case, as (at least from the point of view of 
> encoding) they must be
> handled differently than
>      other kinds of IDs (access ids, accounting ids, etc...).

I don't see this. As far as syntax goes, that's what ASN.1 compilers are
for. As far as semantics, each of these is a special case anyway.

...

> Note that this mechanism also permits issuers to define audit 
> IDs without making
> their use mandatory, which
> we view as a  good thing.

I see this as harmless, but hardly benificial. In our environment we will
always use an audit id for auditing if it is present and not use it for
anything else. Authorization is based on subject and other attributes.

If the net of this proposed change is that it should be possible to issue an
AC with "nothing" but an audit id, I guess that seems reasonable, but it is
not part of our requirements.

> (2)  The draft does not support adequately performant pull-protocol
> implementations.

...

> The combination of these requirements implies that even in 
> pull-protocol
> configurations in which the certificate acceptor
> pulls the AC from a trusted repository over a secure, 
> authenticated link, the
> acceptor must do at least one public-key
> verify operation and a hash.  In high-volume cases, 
> especially those employing
> very short-lived ACs, this will impose
> substantial and perhaps unacceptable overhead.

It is worth pointing out that if the ACs are "very short-lived" that are
likely to be constructed by and retrieved from an AA, not a trusted
repository.

> We propose to add another algorithm to the set: 
> NoHashWithNoEncryption.

We have been considering exactly this optimization. However,I am willing to
concede Stephen's point that this may be out of scope for the IETF, given
there are no IETF defined standards defining a protocol with the specified
properties. (LDAP over TLS anyone?)

As for Russ's question about why use ACs in such an environment, there are
lots of reasons:

1) Well defined format usable with widely available tools
2) Desire to make info available over secure and insecure channels, using
standard and non-standard protocols in a single format
3) Intention to comply with future IETF standards as they are enhanced
4) Market value of "standards compliance" (no flames here, we all know this
matters whether we like it or not)
 
> Now the minor issue:
> 
> (3) We may be confused here, but when section 4.2.7 requires 
> that "AC users MUST
> be able to handle multiple values
> for all attribute types" we see trouble.  Do we really want 
> to REQUIRE support
> for multiple values of Access Identity and Charging Identity 
> attributes?

Given that PKIX is full of such undefined constructs, e.g. semantics of
multiple values in alt name, why pick on these two in particular?

Hal

=======================================================
Harold W. Lockhart            Entegrity Solutions
2 Mount Royal Avenue          Marlborough, MA 01752 USA
V: 1-508-624-9600 x 260       [email-masked]
F: 1-508-229-0338             www.entegrity.com
=======================================================