[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
access-granting protocol (was Re: PK Authentication (...))
At 04:48 PM 4/9/96 -0400, David P. Kemp wrote:
>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?).
I'd have to defer to Perry there.
>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.
Yes, this is FIPS PUB JJJ -- which I actually helped TIS implement for a
firewall proxy. It was based on my experience with that implementation that
I came up with the recommendation for a ticket for the proxy to check --
rather than have it track down certificate chains, deal with X.509 and have
no concept of meaning.
[out of order]
>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.
This might work for a company as small as TIS, but in the example we were
doing at TIS, the firewall was between the internet and milnet, if I
remember correctly, so the idea of having a list of authorized users is
unworkable.
Instead, one needed an authorization certificate or ticket...the thing I've
been describing in cert.html and on this list.
>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.
That's a very good separation of terms. The challenge/response accomplishes
the authentication, but you assumed that the authorization was in the form
of a list of names -- perhaps the DNs in an X.509 certificate. I am
suggesting that:
1) the names are unnecessary -- can be replaced by authorization certificates
2) those authorization certificates can be anonymous since the access
granting code doesn't care about names, but really need a Meaning field
(telling what's being authorized)
3) an authorization check is absolutely necessary and, IMHO, the ticket
should be built into any access-granting protocol
>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.
Agreed. It should be orthogonal to the choice of authentication protocol
[e.g., public key, secret key via auth server, S/Key, ...]. However, the
authorization step itself is needed if we're going to grant access.
Are we agreed that authorization protocol is independent of authentication
protocol but both are necessary components of an access-granting 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.
Except, when we did the proxy demo, we were forced to assume that possession
of a Fortezza card issued by DoD amounted to authorization to access through
the firewall. That is an improper mixing of concepts. The certificate on
the Fortezza card attests only to the existence of a DN in the DoD's name
tree. It says nothing about authorization to access a network. The trouble
was that nothing in Fortezza's X.509 world is equipped to express
authorization -- unless v3 adds a field for such accesses, but I have stated
elsewhere why I believe that approach is unworkable. [the 2048byte cert
buffer on a Fortezza card will soon overflow; there is a security leak in
having permissions available contiguously without need to know; ....]
To come back to your 3 topics:
authentication, authorization, accounting
one might add:
name space management
and note that you probably left it out of your list for the same reason I
left it out of cert.html: that the access-granting protocol doesn't care
about names. Even authorization procedures which operate off of lists of
approved users can keep lists of approved public keys. So I will leave
names out and go back to your 3 items.
Of these, we can not grant access until we have satisfied at least the first
2 of those 3 -- and the accounting (audit log) is just plain good practice
so I see no problem with insisting on it as well.
If I provide the access-granting protocol with my public key and my
authorization ticket [assumed anonymous], then we can achieve all 3 parts:
authentication via JJJ-like chal/resp using my public key, authorization via
the ticket [or a local PK list, in very small cases] and accounting via my
[assumed unique] public key.
- Carl
+--------------------------------------------------------------------------+
|Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme |
|CyberCash, Inc., Suite 430 http://www.cybercash.com/ |
|2100 Reston Parkway PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Reston, VA 22091 Tel: (703) 620-4200 |
+--------------------------------------------------------------------------+