Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))

[Lynn.Wheeler@xxxxxxxxxxxxx]

I've talked to a number of people that have deployed IPSEC &/or VPN in various
business critical environments and view IPSEC as not fullfilling their needs ...
but are using it because the software is easily available at the moment ... and
then cribbing code in behind the IPSEC handshake
to do real-time account lookup as the real arbritrator. If I was asked the
question (about how it fits within existing standards) at the fall, '94 IETF
meeting when the VPN/IPSEC work item was introduce to the router work group ...
I would say that it requires enhancement/development of standards to meet
business requirements.

as to previous comments as to "open" versis "closed" ... most of these are
looking at "open" in the sense that they have a drive towards industry
standards, ISO, IETF, ANSI, etc ... but they are closed in the current
certificate scenerios in that a series of transactions all occur within the
context of a global trust infrastructure typically represented by a number of
real-time status, information, and/or aggregations embodied in an account record
(as opposed to a trust infrastructure that is atomic on a transaction by
transaction basis and covered within the context of information represented by a
certificate manufactored at some point in the past).

it isn't that the cert-less transactions are lacking in trust parameters ... it
is that the atomic nature of cert trust propogation may not represent the
business requirements of a series of transactions (although may be entirely
appropriate for trust propogation in these environments involving sign-up &/or
enrollment transactions).







Stephen Kent <kent@bbn.com> on 07/19/99 01:16:02 PM

To:   Lynn Wheeler/CA/FDMS/FDC@FDC
cc:   "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject:  Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D
           ACTION :draft-ietf-pkix-scvp- 00.txt))




Lynn,

>a cert-less approach is relatively trivial to apply across the
>corporate electronic environment. register the employees public
>key in a RADIUS administrative data-base (i.e. RA by any other
>name) and use RADIUS protocol for all corporate authentications
>i.e. existing RADIUS based authentication and straight forward
>apply RADIUS protocol to future applications.

How exactly does this match with the details of existing, standard
protocols, such as IPsec, SSL, and S/MIME?  I can imagine a scheme by which
this could be made to work, but since these protocols have explicit
provisions for cert (usually X.509 cert) transfer or retrieval., I suspect
that the suggestion you make here is not really compatible with standards
compliant protocols of this sort.  I agree that one might choose to build a
custom application on the basis of cert-less operation.

>This even works in SSL and other types of environments. Consumer's
>authentication at the server is done with RADIUS account-base.

SSL has a specific mechanism for using a client cert for authentication as
part of the SSL handshake.  I don't see how this matches your example,
above.  I think that a browser and server, without modification, will not
be able to take advantage of a client private key based on your description.

>This doesn't say anything about eliminating web server comfort
>certificates ... for setting up SSL sessions ... just addresses issue
>of authenticating individuals in environments that are really account-base
>operation.

We agree that server certs are not the issue here.  But, the standard way
for a cleint to use a public key for auth is as part of the SSL exchange.
Are you proposing a new, independent user auth operation?  If so, then I
agree one could do that, perhaps with a plug-in, but we already have a
means of using a client cert for authentication in SSL, and we have tens of
millions of browsers that are capable of generating key pairs, requesting
certs, and passing certs to servers in a standard fashion.  So, why change?

<snip>

>as alwas choice is:
>
>1) fully defined, identity certificate

What is this, exactly?

>2) relying-party-only certificate where the transaction has to
>hit the account record.
>
>either all the necessary information is in the certificate or the
>certificate contains only enuf information to be able to get
>to the account record. if the operation has to hit the accound
>record anyway ... then it is trivial to show that the certificate
>is redundant and superfulous.
>
>it wasn't intended to be a red herring statement ... it was a
>statement that is was one or the other ... either all the necessary
>information is in the certificate (in which case the certificate can
>represent a privacy and/or security issue) or the information is
>in an account record (in which case the certificate is superfulous
>and redundant).
>
>this of course, doesn't apply to saying that the merchant comfort
>certificates (using for setting up SSL sessions) are unnecessary
>... but that almost all cases that the certificates for employees
>and individuals ... tend to either 1) divulge privacy/confidential
>information or 2) have to hit an account record.

A third choice is to send along an attribute cert (or to embed
authorization data in the public key cert), which is how capability system
is supposed to work (as per the last 25 years of infosec).  This avoids the
need to "hit the account" record, unless access is based on a dynamic
parameter, e.g., for credit card transactions, which is not characteristic
of most intra=net access controls.  In this fashion the organization can
include whetever form of )local) ID it deems appropriate, and the user can
pass in whatever form of authorization credentials are appropriate for the
resource being accessed, avoiding the need for an account record access.
The resource manager does need to check for revocation of the certs in
question, but that may be a cacheable list not requiring the same sort of
off-server access that folks may be envisioning.

Another observation is that the databases for public key management and
authorization management may differ.  If so, a cert-less design might
require two different accesses, one for the public key and one for the
authorization data.  Also, one needs to protect the public key while in
storage and, if the server for the public key is not local to the resource
being access, during  transmission, which is just what a certificate does!
So, cert-less use of public keys does have some possible downsides,
depending on the context.

Steve