Subject: RE: A PKI for the Internet (was RE: Scale (and the SRV record))

From: Alan Lloyd <[email-masked]>
Date: Thu, 5 Nov 1998 10:19:05 +1100

Thanks David - Access Controls without Authentication are not  much use
are they. Perhaps when one looks at PKI and realises that X.509 is used
for "Authentication" of Users - one then may take the next step to say
that this is coupled with ACI for getting at the business data (in the
directories), etc. Then the PKI starts to have some utility.
If the PKI is just used for signing messages, then its limited. But if
its also used for directory access/authentication - then its doing what
X.500 designed it for.

Also - Make that two implementations :-)

regards alan
> -----Original Message-----
> From:	David Boyce [SMTP:[email-masked]]
> Sent:	Saturday, 31 October 1998 2:22
> To:	Al Arsenault
> Cc:	Alan Lloyd; 'Bill Burr'; 'Phillip M Hallam-Baker'; Russ Housley;
> [email-masked]
> Subject:	Re: A PKI for the Internet (was RE: Scale (and the SRV
> record))
> 
> Al Arsenault writes:
> >>
> >>	Isnt it odd that X.509 is used for PKI and X.500 is discounted? 
> >>
> >
> >AWA - X.509 (and ASN.1) are used as a lingua franca of the PKI 
> business.
> >X.509 is not used for its original, X.500-based purpose, which was 
> actually
> >to control access to the directory for the purpose of limiting who 
> could
> >modify entries.
> 
> I'm sorry, Al, but it is factually incorrect to say that X.509 is not
> used for its original, X.500-based purpose.  There is at least one
> commercial implementation of X.500 which supports strong
> authentication
> using X.509 certificates, and makes use of the fact for Access Control
> purposes.
> 
> I'll grant that X.509 is being used beyond its original purpose, but
> that's just a measure of its utility.
> 
> David.
> -- 
> David Boyce
> 
> Tel:	+44 181 332 9091		Richmond, Surrey, ENGLAND
> Email:	[email-masked]	Isode's WWW:
> http://www.isode.com/
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 4 Nov 1998 22:55:00 -0500

Lynn,

>while the current common certificate infrastructure model is SSL ... which
>baiscally checks if the certificate has been manufactored by somebody in
>the list of known certificate manufactors/issuers (aka CAs) .... the common
>authentication model on the internet is logging on to the service provider.

Well, that depends.  For most corporate Internet users, this model is not
at all common.  For redidential subscribers, it is.

>This one is basically somebody signs up for an account and establishes a
>password. When they want to use the internet ... they contact the router,
>give their account name and proof of password. The router is likely running
>something like radius ... in which case it forwards the account name and
>password to an account authenticator.

You contact something like a PPP server, not a router per se.  The RADIUS
server is likely running elsewhere; after all, it's a server.

>For PKIX to address the most fundamental of internet authentication
>requirements ... could involve the ISP issuing a relying party certificate
>with just the account name (sidestepping liability and privacy issues). The
>choice now would be would the ISP router accept the certificate
>authentication at face-value ... or would it use a PKI flavor of radius to
>contact an account authenticator .... for instance to have more timely
>information on whether the account is in good standing.

Because not all subscribers necessarily have the same privileges, mere
verification of the cert provides authentication, but not authorization. So
it would be quite reasonable for the ISP to check a database to see such
things as where the user is allowed to connect, what QoS features he may
elect, etc.  That check against an access control database is a fine time
to check for revocation, precisely because the ISP is both the CA and the
consumer of the cert.

>This is possibly the most fundamental current internet requirement ... and
>it illustrates again the extremely short step from relying party
>certificates to the AADS model ... where if the account has to be touched
>as part of the authentication/authoritization ... then it is easily shown
>that shipping the certificate with the transaction is superfulous (if
>somebody gives you a copy of something .... how many million times do you
>have to send the same copy back to them ... before they realize that they
>don't have to see the copy if they are already looking at the original
>stored in the account record).

Note that my example still differentiates between authentication and
authorization.  Sending in the user's cert is just a convenient way to
package the public key and the ID it represents.  Nothing wrong with that.

Steve

---

From: [email-masked]
Date: Wed, 4 Nov 1998 21:38:00 -0800

if the public key is already bound to attributes in an account record then
the certificate represents duplicate function from what is in the account
record (i.e. since the attributes and the public key would already be in
the account record .... then having to send in the certificate at all is
superfulous ... as well as validating if the certificate is still good,
validating the CA-signing key on the certificate, validating the CA
certificate, validating if the CA certificate is still good, validating the
CA-CA-signing key on the CA-certificate, ... on up to the root
certificate).

For authentication, there needs to be owners digital signature on at least
the account-number and time-stamp or sequence number  (i.e. the owner has
to sign something to show that it possesses the corresponding private key
and that it isn't a replay). Also sending the certificate is superfulous if
the account record has to be accessed (also containing the public key).

Including the certificate can have additional downside (in addition to
being superfolous):
    1) unecessary increased bandwidth
    2) increased systemic risk because of uncessary dependency on
CA-infrastructure
    3) possible attacks based on attributes duplicated in the certificate
that have real-time characteristics and become stale. .... and trying to
precipitate authorization decisions based on the stale data.

Furthermore attributes/information in the

---

From: [email-masked]
Date: Wed, 4 Nov 1998 22:36:00 -0800

for the most part routers now use PPP on point-to-point links (i.e. point
to point protocol)  .... typically having modems ... these modem links can
vary from the 14.4 modem banks at a ISP ... to a T3 WAN connection into the
backbone (if you configure you companies router connection into an ISP ...
you could be asked to specify various sorts of PPP parameters for the WAN
connection).

I first used radius on the livingston portmaster with a bank of 14.4 modems
... and it was typically deployed with radius server code running on a unix
login machine .... where the unix machine was configured with
userids/passwords for everything that was allowed to access the portmaster.
The radius server code originally did a unix password operation for the
indicated userid ... to verify a valid portmaster connection.

If you want to see more on radius .... see:

               http://www.garlic.com/~lynn/rfcietf.html

(or pick up the pointer from the RFC editor's page), then click on frames
version, then click on "Term". The Term abbreviations will include Radius
which you can click on ... which will give you list of all the RFC
concerning Radius

from 2058 ....

Managing dispersed serial line and modem pools for large numbers of
   users can create the need for significant administrative support.
   Since modem pools are by definition a link to the outside world, they
   require careful attention to security, authorization and accounting.
   This can be best achieved by managing a single "database" of users,
   which allows for authentication (verifying user name and password) as
   well as configuration information detailing the type of service to
   deliver to the user (for example, SLIP, PPP, telnet, rlogin).

   Key features of RADIUS are:

Client/Server Model

      A Network Access Server (NAS) operates as a client of RADIUS.  The
      client is responsible for passing user information to designated
      RADIUS servers, and then acting on the response which is returned.

      RADIUS servers are responsible for receiving user connection
      requests, authenticating the user, and then returning all
      configuration information necessary for the client to deliver
      service to the user.

      A RADIUS server can act as a proxy client to other RADIUS servers
      or other kinds of authentication servers..