[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

PK Authentication (was Re: Example 2: ...)

> Date: Fri, 05 Apr 1996 16:46:45 -0500
> To: spki@c2.org
> From: Carl Ellison <cme@cybercash.com>
> Subject: Example 2: POP server, telnet proxy, ftp proxy, ....
> 
> Here's another real example, today.
> 
> I have several servers I connect to to get my work done.  POP3, telnet, FTP,
> ....  They want me to authenticate myself.
> 
> In a few cases I have S/Key available and others demand fixed passwords but
> I'd like a nice uniform PK mechanism for authentication.  As I see what
> people are doing with PK mechanisms, uniformity seems a lost cause.
> 
> The one example I have seen was tied to X.509 certificates and Fortezza.
> Let's consider one for the Internet community, using RSA and something more
> reasonable than X.509 but one that works even with Fortezza.


An uniform PK Authentication mechanism is an urgent need right now, for
the applications you mentioned and others:

   POP3 (or preferably, IMAP4) mail servers
   telnet and FTP servers
   authentication to firewall proxies (telnet/ftp/rlogin/http/etc)
      using SOCKS v5
   authentication to individual hosts at the console (login, CDE dtlogin)
      using OSF Pluggable Authentication Modules (PAM) - obviously to make
      any sense in a console login scenario, user authentication must be
      based on a hardware token, not already resident on the host!
   dial-up network access servers using RADIUS or TACACS+
   login to yukky things like Netware, Notes, SMB, etc :-)
   and in general, anywhere OTP (S/Key(tm)) or handheld authentication
      tokens (SecureID, etc) are or could be used.

This is important enough to merit it's own IETF WG, but if enough spki
participants feel it is in scope, perhaps a PK authentication protocol
could be identifed as a product of this group. (I haven't seen a formal
charter yet, does one exist?).

NIST has done some work in this area - an old draft of the Public Key
Authentication Standard (PKAS) is currently on their server, but a new
version (29 March 1996) should be posted soon at
http://csrc.ncsl.nist.gov/fips/pkauth.txt.  The NIST PKAS is based on a
subset of the ISO/IEC 9798-3 standard.  It contains an example encoding
using ASN.1, but it is tied to neither ASN.1 nor X.509 certificates -
it's flexible enough to accommodate almost any protocol.  For example
it also includes an encoding based on NorTel's SPKM, which is defined
in terms of bits-in-boxes, not ASN.1.

Two basic design decisions are incorporated in the NIST PKAS:

  1) it is based on public key digital signatures, not symmetric
     key distribution systems like Kerberos, and not one-way hashing
     like One Time Passwords.

  2) it uses a challenge / response protocol, not timestamps/sequence
     numbers like X.509 authentication, to eliminate the complications
     of clock synchronization, validity intervals, replay detection,
     etc.  Timestamp-based authentication is just too cumbersome for
     large-scale systems.

The basic protocol for Alice to authenticate herself to Bob is:

  1) Bob->Alice:    Rb
  2) Alice->Bob:    Ra | Sig_a(Ra | Rb)

For mutual authentication, a third step is added:

  3) Bob->Alice:    Sig_b(Rb | Ra)

where Ra and Rb are nonces (non-repeating numbers) generated by
Alice and Bob respectively, and Sig_a and Sig_b are their respective
digital signatures.  "|" indicates concatenation.

There are additional optional fields for token (transmission) IDs,
entity IDs (names), certificates, and arbitrary unsigned and signed
data.  The public key(s) needed to verify the signatures can be identified
in three ways: 1) out of band (i.e. from the username given in a login
request before the challenge is issued), 2) from an entity ID included
in the exchange (I too like the idea of using the hash of the public key
as the entity ID), or 3) from a certificate or certificate chain included
in the exchange.

> ----------------------------------------
> 
> The code which evaluates permission needs very little.  It has to check a
> certificate for the caller but it doesn't want to know anything about names.
> So, since some people think "certificate" implies names, let me call this a
> ticket (ala Kerberos) [or capability (ala Lampson)].
> 
> All the FTP proxy or POP server needs is the following information:
> 
>         [ signee, signer, validity, meaning ]_signer
> 
> ie., a message signed by the signer which contains:
> 
> signee: the public key of the signee [or a hash of it, ala Greg's suggestion
> which I'm coming to like more and more]
> 
> signer: the hash of the public key of the signer
> 
> validity: a date range
> 
> meaning: "the signee is allowed FTP access to cybercash.com" or
> "ftp://cybercash.com/"
> 
> It's up to the proxy to know the public key of the one or two entities
> authorized to give the permission it cares about, so no more than a hash is
> needed of the signer's key.
> 
> If there's a more complex structure, including certificate chains or CRLs or
> whatever, giving this permission, then that structure can be evaluated in
> non-real-time and used to generate a ticket like the one above (which is
> stripped down for real-time use).
> 
> With that ticket, the proxy gives service or denies it based on generating a
> random challenge and getting back a signature of it.
>
> ----------------------

I believe there is advantage in clearly separating the concepts
of Authentication, Authorization, and Accounting.  The Authentication
protocol might carry an Authorization "ticket" as shown above as an
incidental part of it's payload, but should not require it.  The
challenge and signature is what actually accomplishes the authentication.

In many cases, the authorization list will be relatively static and
manually configured by an administrator.  ftpd at cybercash.com might
have a fixed list of IDs it will allow in.  But if an authorization
protocol is defined to allow passing of capabilities (from an auth
server to the ftp proxy, for example, or from the auth server to the
client to the proxy), it should be orthogonal to the authentication
protocol.

In the example above, the ftp client signs a challenge and returns
it to the proxy using a protocol that should be well enough specified
to allow interoperability between independent implementations.  If
any tickets are involved, they should be opaque blobs as far as that
authentication protocol is concerned.

I am working on a draft of such a protocol.  If there is sufficient
interest, I'll post it here in a couple of weeks.