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

From: "Flanigan, Bill" <[email-masked]>
Date: Wed, 14 Jul 1999 09:03:04 -0400

Hello Mike,

	You are on the right track (and so, I think, is Steve).  Before PKI
technologies (and other IETF *core* security protocol suites) can be *main
streamed,* they must be made very easy to use across the board--from
implementers to developers to end (human) entities.  Some might object to
this as being *dumbed down,* but lack of interoperability due to overly
complex and convoluted multi-protocols (not to mention competing protocols)
is a real problem.  So is the resulting complexity of use experienced by EEs
(I could write volumes here!).  Unless we aim for the *lowest common
denominator,* CIOs will never be able to show ROIs to justify PKI (and
especially the PKIX favor of PKI) purchases.  We have probably all read
recent reports that Fortune 1,000 CEOs see IT, in general, and PKI, in
particular, as simply drains on profits; and in the UK, companies don't seem
to be interested in PKI (and especially the PKIX flavor of PKI) at all.  As
usual, KISS is the key (no pun intended).  I fear that we do not have the
luxury of tossing things over the fence to *let the market decide.*  The
market may decide to pass.

Bill

> ----------
> From: 	Michael Myers[SMTP:[email-masked]]
> Sent: 	Tuesday, July 13, 1999 9:29 PM
> To: 	'Stephen Kent'; Anders Rundgren
> Cc: 	'Peter Sylvester'; [email-masked]'
> Subject: 	RE: ASN.1 vs XML (used to be RE: I-D
> ACTION:draft-ietf-pkix-scvp- 00.txt)
> 
> Steve,
> 
> I'll probably bring this point to your attention on the floor before you
> read this email, but for the record (and further, for the benefit of those
> unable to attend the Oslo session), I would claim that making PKI easy for
> developers is a very good thing.  Your comment belows seems to modestly
> suggest that such an objective is less worthy than it might ought to be.
> 
> Indeed, this principle was the primary motivation for OCSP's original
> non-ASN.1 proposal.
> 
> Mike
> 
> 
> 
> > -----Original Message-----
> > From: Stephen Kent [mailto:[email-masked]]
> > Sent: Tuesday, July 13, 1999 12:28 AM
> > To: Anders Rundgren
> > Cc: 'Peter Sylvester'; [email-masked]'
> > Subject: RE: ASN.1 vs XML (used to be RE: I-D
> > ACTION:draft-ietf-pkix-scvp-00.txt)
> > 
> > 
> > Anders,
> > 
> > 
> > >The important thing is that in order to make PKI a 
> > main-stream technology
> > >(which it is
> > >not today), may require changes like going to XML as XML is likely to
> > >at least replace EDI which is often used in the same contexts as
> > >certificates (or
> > >rather should be).  So if XML becomes the HTML (which is closer to a
> > >"peoples movement" than a computer language) of business 
> > messages, ASN.1
> > >may be too obscure (few know it) and less satisfactory as a long-term
> > >solution.
> > >
> > >This should be seen in the light of the fact that the only 
> > main-stream
> > >PKI-application
> > >I can think about, is e-commerce.  As very few e-commerce 
> > standards are ready
> > >for prime time, there is plenty of room for new things.
> > 
> > There seems to be an implication here that mainstream users 
> > want to be able
> > to read the signed data in its native format, and thus XML encoding is
> > preferable to DER.  But we know this is not true, i.e., 
> > whatever has been
> > signed will be decoded prior to display, and then rendered 
> > for the user.
> > So, it would seem that the use of an encoding scheme such as 
> > XML would be
> > more attractive for developers performing debugging, rather 
> > than for users.
> > 
> > Steve
> > 
>

---

From: "Aram Perez" <[email-masked]>
Date: Fri, 16 Jul 1999 11:17:33 -0700

Eric Guerrino wrote:

[snip]
> 
> I initially was led to believe PKI supported non-repudiation because this
> was one of the claims being made for it by its proponents. It was only
> after I started examining it more closely that I realized the claims were
> unsubstantiated. As long as one party can reasonably deny a fact, it is up
> to the other party to prove otherwise. If I receive a transaction and act
> on it, and the initiator subsequently denies the transaction, what do I
> have to authenticate the user and the data? I can't claim in court that I
> received and acted on a message because my server accepted it since it came
> with a valid certificate,  and because the signature and the message digest
> were valid, based on the certificate. I need to to be able to produce the
> original message, the digest, the signature, and the certificate, and be
> able to show that the validity checks all passed. I also need to know what
> algoritms were used. I need logs and audit records to prove the transaction
> came in. And I need all this possibly months or years later. But, most of
> all, I need to be able to demonstrate that I based my decision on
> reasonable assurance that the originator was who they claimed to be.

I'm glad you've come to this conclusion. I've stated numerous times that
digital signatures DO NOT provide non-repudiation. When you verify a digital
signature, all you can assert is that the data was not tampered with, and
that the private key (that corresponds to the public key in the certificate)
was used to generate the digital signature. Having said that, I do believe
that what digital signatures do provide is "strong evidence for the rebuttal
of a repudiation."

>
> Which brings me to userids and passwords, and why I must use an application
> password even if I have issued a certificate.  Passwords provide reasonable
> assurance to me that the originator is who they say they are; as long as
> the password is kept securely.

But this is the same assumption you make about a private key, that it is
kept securely.

> Dynamic passwords (two-factor
> authentication) provide even stronger assurance that this is so. What do I,
> as a verifier, have when a certificate is used? I have no reasonable
> assurance about the originator because I have not done anything to
> authenticate them.

It all depends on the protocol. A good PKI-based protocol would use a
challenge-response mechanism.

> I don't know how secure the originator's PC is.

You have this problem with passwords also.

> I don't
> know if they have told the browser to cache the private key password, nor
> the strength of it. I don't know if their PC will lock itself after a
> certain amount of inactivity. I don't know who has access to the PC. It is
> not difficult to copy certificate files from one system to another.

Copying certificates is not an issue. By definition, a certificate is
"public".

> If the
> password is not strong enough, it probably would not be too difficult to
> crack it.

There are numerous accounts of how to break MS passwords and key storage.

> The certificate would be more reliable, for user authentication
> purposes, if I, as an issuer, could control usage of the private key

But how can an issuer (I'm assuming you mean a certificate issuer) control
the use of the private key?

> and
> user authentication, or, minimally, if It is stored on some external
> device.

Hence the attractiveness of tokens like smart cards.

> At least this provides two-factor authentication. I can't control
> how software vendors utilize certificates in their browser products, but I
> am at their mercy if I allow my application to run from their browser. If
> risk assessment requires me to use password security anyway, I need to be
> able to show significant incremental value added by certificates, given
> that the certifcate process places a large administrative burden around all
> this.

The "significant incremental value" is the elimination of users having a
different password (a good security practice) for every system that have
access to.

>
> Granted, all this is less confusing if an originator is executing a
> transaction with the issuer of the cetificate, because the issuer could
> control the user authentication process. But it becomes more complex when
> the certificate is used to execute a transaction with a third party. How
> can a bank verify a certificate and, more importantly, vouch for a
> transaction, if it can't be reasonably assured the customer is who they
> claim to be? All it has is a request for validation from the third party
> (merchant) and a message.

If the bank does not trust the root CA (and its certificate), it will not
vouch for the transaction. This is one of the reasons the root certificates
have to be verified by an out-of-band mechanism. You are a great risk if you
accept a new root certificate blindly.

[snip]

Regards,
Aram Perez

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 19 Jul 1999 15:58:49 +0200

Stephen W,
<snip>
>As an example, I am using a certificate Smartcard with a pin-number
>protected private key for VPN access to my head office.  If the laptop and
>smartcard are stolen, the thief can play with them until he has cracked the
>pin number. The thief can do this off-line with no contact with the VPN
>server. Once cracked, they can connect to the Internet, and contact the VPN
>server.

Is it that easy?
I doubt that a thief can "play" with the smart-card until he/she cracks the PIN-code.

After lets say tree tries most smart-cards become  "neutralized" and requires a
much harder PUK-code to be reactivated.  It is also easy for a smart-card
to introduce a for a human negligible delay that makes computerized attacks
less fruitful.

The only method I know of requires opening the chip and manipulations at silicon-
level.  This is not for everybody.

Anders

---

From: [email-masked]
Date: Mon, 19 Jul 1999 14:32:24 -0700

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 <[email-masked]> on 07/19/99 01:16:02 PM

To:   Lynn Wheeler/CA/FDMS/FDC@FDC
cc:   "[email-masked]'" <[email-masked]>
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

---

From: [email-masked]
Date: Mon, 19 Jul 1999 14:50:33 -0700

re: authorization/authentication seperation

this is not in terms of technolgy or security seperation ... this is in terms of
business interest seperation .... i.e. would the US dod contract to a another
contry's  military organization to do the preliminary authentication on all US
military SBU and top secret messages ... allowing them to  decide which messages
are flagged as correctly authenticated and which message are flagged as
non-authenticated??? this is further exasberated by the fact the US
would be in direct conflict with with the country that has the military
organization that has been selected to preprocess and authenticate US military
traffic on behalf ot the US military.

There is all sorts of opportunity for fraud when the business interests of the
organization doing authentication is in conflict with the business interests of
the organization authorizing and executing the transactions.

one of the reasons for reg. E is that it is readily recognized that the merchant
interests and the consumer interests do not coincide 100% ... furthermore ...
merchant banks representing merchants and consumer banks representing consumers
... are also representing conflicting interests.

---

From: [email-masked]
Date: Mon, 19 Jul 1999 18:16:19 -0700

re: subcontracting out authentication;

no, the example was to indicate that the seperation of authentication and
authorization isn't within the same business unit ... but totally different
organizations ... the characterization was that authentication and authorization
has been seperated so far into different factions where the authentication
function has actually was really (as silly as it may seem) subcontracted out to
the opposing forrce ... i.e. DOD didn't subcontract DOD certificate authorities
to USPS or some government agency ... but actually subcontracted out DOD
internal authentication function to a foreign government ... one that is even at
odds with the interests of the US government. The degree of the seperation of
authentication and authorization is to the extent totally differenent
business/company/country has been asked to do all of your authentication ...
even tho the agency in question doesn't have your best interests at heart (and
in fact may have interests that are improved if false authentication occurs).

It is like in the home business ... they typically recommend that a buyer get
their own lawyer and not expect the seller's lawyer and/or seller's real estate
agent to act in the buyer's interest ...

re: account records

while account records are frequently motivated by financially related matters
... they aren't unique to the financial industry. nearly every business interest
operates off account records. within the pervue of the IETF ... every ISP
offering internet service for sale operates off account records (amount of
service, quality of service, whether it is currently active or not, has this
month's bill been paid, etc). So I wouldn't want to characterize that only
financial institutions are uniquely motivated as having account record driven
business.