[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
----------------------------------------
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.
----------------------
Why generate tickets?
1) this keeps down the code size and execution time of the proxy to a bare
minimum
2) some people will get tickets generated directly [like I have with the
card that lets me into the CyberCash offices]
3) any authorization mechanism [even the dreaded X.509v3 stuff] can be
evaluated by an oracle to establish permission and the duration of that
permission which could then generate a date range ticket. The date range
would be limited to the CRL lifetime, if CRLs are used, but it's still a
date range.
- 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 |
+--------------------------------------------------------------------------+
Follow-Ups: