Subject: Comments: An Intranet Attribute Certificate Profile for Authorization

From: [email-masked]
Date: Wed, 5 Jul 2000 16:23:00 -0500

All,

We have some comments below related to "An Intranet Attribute Certificate
Profile for Authorization"  <draft-ietf-pkix-ac509prof-03.txt>.

Paul.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

We have two major issues and one minor issue.  First, the major issues:
(1) The draft does not adequately support anonymous operations with audit id.

     Section 4.3.1 requires the audit id to be a critical extension rather than
an attribute

     Section 4.2.7 requires the AC to have at least one attribute

     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.

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

We propose the following fix to the problem.  The rationale behind making audit
IDs critical extensions is that
issuers want to constrain implementations which accept their ACs with audit IDs
in them to treat audit ids properly -- that
is, they want to constrain acceptors of their ACs to put only audit IDs into
audit records.

Proposal:

The goal can be accomplished by defining the audit id as an attribute, and
defining a separate a "UseAuditID" extension.
If the "UseAuditID" extension is present, the accepting implementation must
never put any attribute other than the
audit ID into an audit event.

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

We propose that 4.4 be updated to define audit ID as an attribute, and that
4.3.1 be updated to define the UseAuditID extension
instead of the current Audit Identity extension.

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

     Section 3 defines support for pull-protocol use of ACs as a requirement

     Section 4.2.4 requires that the AC signature MUST be md5WithRSAEncryption,
id-dsa-with-sha1,
     sha-1WithRSAEncryption, or ecdsa-with-SHA1.

     Section 5 requires that the signature must verify (path and crypto) or else
be rejected.

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.

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

Specifically, we propose that the text of the last two paragraphs of 4.2.4 be
changed to read:

     This MUST be one of the following algorithms: NoHashWithNoEncryption,
md5WithRSAEncryption,
     id-dsa-with-sha1, sha-1WithRSAEncryption, or ecdsa-with-SHA1.  [PKIXPROF]
section 7.2 defines
     md5WithRSAEncryption, id-dsa-with-sha1, and sha-1WithRSAEncryption.
[ECDSA] section 3.2
     defines ecdsa-with-SHA1.  NoHashWithNoEncryption indicates that no
signature has been applied
     to the attribute certificate; if this signature algorithm is specified, the
certificate passes the signature
     validity check with no processing required.

     id-dsa-with-sha1 MUST be supported by all AC users.  md5WithRSAEncryption,
sha-1WithRSAEncryption,
     and ecdsa-with-SHA1 SHOULD be supported.  NoHashWithNoEncryption MAY be
supported.

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?

Paul Ashley, PhD
Senior Security Architect
Tivoli Security Business Unit

Bridgepoint III
6300 BridgePoint Parkway
Office A5022
Austin, Tx 78731

email: [email-masked]
phone: +1 (512) 436 1541
fax: +1(512)436-1199
cell: (512) 695 1821

Tivoli - an IBM division

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 06 Jul 2000 12:09:52 +0100

Hi Paul,

I'm afraid I don't really agree with your proposals.

I don't see much difference between the audit id as is, and
your proposal, and I'm not sure I like an AC with an audit-id
attribute and no critical extensions being conformant. I'll 
think about it though - if lots of folks agreed, I'd be willing 
to take it (so far, you're the second, Bob Blakely was the 
first:-).

I really don't like your no-hash-no-sig suggestion and I don't
think it fits in this spec anyway. nHnS could only be used 
where there was also an interoperable secure AC transport
scheme defined (or else you're back in proprietary land), 
which is definitely out of scope for the profile. There'd 
also be some process issues - it is the PKIX WG after all, 
and folks have been beaten up for suggesting dummy algorithms
in the past. I'd suggest you write an I-D, based on the profile, 
defining the secure transport and adding nHnS as an 
algorithm (BTW: where's that defined?) 

For issue 3, yes we meant that everyone has to be able to
parse multivalued. I don't think we should get any more
restrictive in the profile.

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: Russ Housley <[email-masked]>
Date: Thu, 06 Jul 2000 15:45:41 -0400

Paul:

1.  I am not very happy with your proposal.  I would be willing to make the 
audit identifier an attribute, but I see no utility in the extension that 
you propose.

2.  I see no value in unsigned attribute certificates.  If you have a 
secure means of pulling attributes about a subject from a server, why use 
attribute certificates at all?

Russ

At 04:23 PM 07/05/2000 -0500, [email-masked] wrote:
>--------------------------------------------------------------------------- 
>--------------------------------------------------------------------------- 
>--------------
>
>