2008/525 ikeadm token login

[Bill Sommerfeld]

I'm sponsoring this fasttrack for Paul Wernau.  Timer expires on
8/22/2008.  Release binding is Patch/Micro.  The new ikeadm and ikecert
subcommands, options, and associated behavior have a Committed stability
level.


Description:
------------

Private keys for IPsec/IKE are currently stored in the clear on disk or 
the pin for a PKCS#11 token is stored in the clear.  What this 
effectively means is that anyone with root access to a system has access 
to use the private keys.  In the case of someone without a PKCS#11 
hardware token device, they can potentially clone the keys, either by 
taking the on-disk private key file directly or by copying the PKCS#11 
softtoken keystore and noting the pin.  If the pin were not stored in 
the clear on disk, the softtoken store would be mostly useless.  Even in 
the case of a hardware keystore, root access to the system means 
immediate access to use the keys indirectly.

Consumers in highly secure environments need the ability to be able to 
control use of keying material.  Mobile users or users with smartcard 
devices, which store private keying material on the cards themselves, 
need the ability to be protected in the case of stolen device(s). 
Keeping the pin on disk with a smartcard also violates the "something 
you have, something you know" principle, as you don't need to know the pin.

The reason that the pin is currently stored in the clear is that the 
in.iked service starts up on boot and needs the pin to access keying 
material.  A similar bootstrapping problem has existed for some time 
with SSL on webservers.  The service can't start until someone unlocks 
the key, which affects availability.  It is up to the administrator of 
the webserver whether user invention is required by site policy.  We 
intend to allow Solaris IPsec/IKE administrators the same choice.

Proposal:
---------

This project allows in.iked(1m) to start in a mode with PKCS#11 token 
store backed private keys initially locked, allowing the administrator 
to unlock them later on a running in.iked process.  Administrators will 
have the ability to store the pin in the clear, but will default to 
being locked until opened.

Additionally, an observability mechanism will be added to ikeadm(1m) to 
allow the user to observe the contents of the certificate cache and the 
status of the associated keys, if any.

Details:
--------

In the case that the pin is stored in the clear on disk, operations will 
continue as normal.  In the case that pin is required, ikeadm(1m) will 
be extended to unlock the private key as follows:

  # ikeadm token login <Token Device>

e.g.

  # ikeadm token login "Sun Metaslot"
  Enter PIN for PKCS#11 token:
  ikeadm: PKCS#11 operation successful

ikeadm(1m) will be extended to dump the certificate cache so one can see 
the status.  In the case of this object, we see the following on an 
unlocked token.


  # ikeadm dump certcache

  [SNIP]

  CERTIFICATE CACHE ID: 11
         Subject Name: <CN=fagiole metaslot>
          Issuer Name: <CN=fagiole metaslot>
                 [trusted certificate]
                 [Private key available]

To make the key inaccessible, ikeadm(1m) is extended to lock the PKCS#11 
backed private key as follows:

  # ikeadm token logout <Token Device>

e.g.

  # ikeadm token logout "Sun Metaslot"
  ikeadm: PKCS#11 operation successful

The certcache subcommand will show the private key in a locked position, 
as follows, either before a login or after a logout.

  # ikeadm dump certcache

  CERTIFICATE CACHE ID: 11
         Subject Name: <CN=fagiole metaslot>
          Issuer Name: <CN=fagiole metaslot>
                 [trusted certificate]
                 [Private key linked but locked]

In the cases of login and logout, the operation is applied to all 
objects on the PKCS#11 token, as the PKCS#11 spec has users unlock the 
token itself, not individual objects.

ikecert(1m) will be changed so that the pin is not stored in the clear 
on disk unless the -p option is given.

e.g. This syntax does not store the pin in the clear.

  # ikecert certlocal -ks -t rsa-sha1 -m 1024 -T "Sun Metaslot" \
    -D "CN=pinnotinclear, O=Sun, C=US"
  Creating private key.
  Enter PIN for PKCS#11 token:

This syntax would be:

  # ikecert certlocal -ks -t rsa-sha1 -m 1024 -T "Sun Metaslot" \
    -p -D "CN=pininclear, O=Sun, C=US"
  Creating private key.
  Enter PIN for PKCS#11 token:

The existing -U (unlink) and -L (link) options, combined with or without 
the existence of -p can be use to migrate from one format to another.