[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A day in the life of ephemeral certificates
Marcus Leech writes:
>I've been doing more thinking about realistic scenarios for the use of >ephemeral certificates.
Here is a closely related usage that ephemeral certificates may address.
Have you ever had the need to grant to someone, on your authority, temporary
access to systems to which you have access? (The "someone" may be a colleague
within your organization, or an outside vendor-software-troubleshooter.)
Today, this temporary access is often accomplished one of two ways:
1. Set up actual accounts for this user.
Problems: This usually requires priviledge beyond your ordinary access
to these systems, and requires understanding how to properly create such
accounts. Since many systems do not support automatic account expiration,
you must remember to remove such accounts. None of this lends itself to
automation.
2. Call them on the phone and give them your password.
Problems: This is a terrible idea, but some folks do it regularly since
it is easy. There is little way to track such delegation of access, nor
an easy way to revoke it.
I haven't thought through the details here, but is seems that you could use
the outsider's ID-based cert to securely obtain temp keys they generate, as
well as their location, and then sign an ephemeral certificate (with your
own ID-cert) to the effect that this outsider's credentials are as good as
yours (for the given access usage) for the next three hours.
This also provides a record of your delegation of access.
Marcus Leech continues:
>I log in to my workstation in the morning:
>
> 1) I pick a key-pair from a pool that my workstation has generated for
> me overnight.
>
> 2) I unlock the private key of my identity-based (long-term) certificate
>
> 3) Using that certificate, I:
>
> Obtain Kerberos Ticket Granting Tickets from each of the KDCs
> that I normally need TGTs from
>
> Obtain ephemeral privilege granting certficates from each of
> the PGAs (Privilege Granting Authorities) that I normally need
> to acquire privilege from. Those ephemeral certificates mention
> the public key from the key-pair I had selected earlier.
>
>
> 4) I use services that require the use of either Kerberos tickets or
> these fancy ephemeral certificate things.
>
> I can envision using one of these PGCs (Privilege Granting Certificates)
> to establish, as required, a "security association" with host systems
> that I normally interact with. Once I have one of these SAs, I don't
> need to use the PGC with the target host again until my SA expires.
> The target host would naturally cache my "privilege vectors" when
> it creates an SA. You don't get non-repudiation for transactions
> protected by such an SA, but often you don't need that. Indeed, in
> the day-to-day network-login, network-copy, network-this-and-that
> scenario, you care only that your messages are protected, and that
> the target host has some confidence in the privileges associated with
> those messages. I can envision "unix-login-id" being one of the
> "privileges" (capabilities?) that might be associated with a PGC.
>
> In a large corporation, there would likely be many PGAs, with
> a given identity having, for example, different "unix-login-id"
> capabilities in different domains (from different PGAs).
>
>----------------------------------------------------------------------
>Marcus Leech Mail: Dept 4C16, MS 238, CAR
>Systems Security Architect Phone : (ESN) 395-4901 (613) 763-9145
>Systems Security Services Fax : (ESN) 393-7679 (613) 763-7679
>Nortel Technologies mleech@bnr.ca
>-----------------Expressed opinions are my own, not my employers------
Tony Bartoletti LL
SPI Project Leader LL LL
Computer Security Technology Center LL LL LL
Lawrence Livermore National Lab LL LL LL
PO Box 808, L - 303 LL LL LLLLLLLL
Livermore, CA 94551-9900 LL LLLLLLLL
email: azb@llnl.gov phone: 510-422-3881 LLLLLLLL