[security-dev 01526]: Re: RFC: keytab automatic refresh in Java

[Max (Weijun) Wang]

Hi Security-dev

Here is the draft of the new proposal:

6894072: 	always refresh keytab

State: 	draft

Problem:

Currently JAAS's Krb5LoginModule reads the content of a keytab file at  
the commit time and never touches it again. This means during the  
whole lifetime of the Kerberos service, there is no chance to renew or  
revoke keys for it. The only way to let it read the keytab again is to  
restart the JAAS login/commit process.

Also, this means keys must be created before the JAAS login.

The reason is that we now store KerberosKey objects as private  
credentials in the JAAS Subject.

MIT and Solaris Kerberos re-reads the keytab whenever it needs to use  
a key from it.

Solution:

When keytab is used, instead of KerberosKey objects, we store a KeyTab  
object into the private credentials set of the JAAS Subject. There is  
still a getKeys() method for the new KeyTab class, and this method  
makes sure that the output always reflects the current content of the  
keytab source file.

Interface summary:

exported    	external    	class    	 
javax.security.auth.kerberos.KeyTab	    	3 methods

Specification:

/**
  * This class encapsulates a keytab source.<p>
  *
  * A Kerberos JAAS login module that obtains long term secret keys  
from a
  * keytab source should use this class. The login module will store
  * an instance of this class in the private credential set of a
  * {@link javax.security.auth.Subject Subject} during the commit  
phase of the
  * authentication process.<p>
  *
  * The <code>readKeys</code> method can be used to retrieve secret  
keys for a
  * given service. This class should make sure that the returned keys  
must match
  * the latest status of the keytab source. Therefore, applications  
are not
  * advised to call the method pre-maturely or cache the result.<p>
  *
  * It might be necessary for the application to be granted a
  * {@link javax.security.auth.PrivateCredentialPermission
  * PrivateCredentialPermission} if it needs to access the KerberosKey
  * instance from a Subject. This permission is not needed when the
  * application depends on the default JGSS Kerberos mechanism to  
access the
  * KerberosKey. In that case, however, the application will need an
  * appropriate
  * {@link javax.security.auth.kerberos.ServicePermission  
ServicePermission}.
  * Permissions.
  *
  * @since 1.7
  */
public final class KeyTab implements Serializable {

     /**
      * The src of this keytab.
      *
      * @serial
      */
     private final String src;

     /**
      * Returns a <code>KeyTab</code> instance. The result is never  
null even
      * if the source is missing. In this case, its <code>isMissing</ 
code>
      * method returns <code>true</code>.
      *
      * @param src the source of the keytab to be returned, say, a  
file name.
      * @return the keytab instance (never null)
      */
     public static KeyTab getInstance(String src);

     /**
      * Returns keys for the given Kerberos principal. The result can  
be modified
      * by caller without damaging the keytab object. Callers are  
advised to
      * destroy the result keys after they are used.
      *
      * @param principal the Kerberos principal
      * @return the keys (never null, may be empty)
      */
     public KerberosKey[] getKeys(KerberosPrincipal principal);

     /**
      * Returns if the keytab source is missing. Users can use the  
result to
      * determine if they should fallback to another mechanism to get  
the keys.
      * @return true if the keytab source is missing.
      */
     public boolean isMissing();
}

Also, make the following change to the current classdoc of  
javax.security.auth.kerberos.KerberosKey class:

   * All Kerberos JAAS login modules that obtain a principal's  
password and
- * generate the secret key from it should use this class. Where  
available,
- * the login module might even read this secret key directly from a
- * Kerberos "keytab". Sometimes, such as when authenticating a server  
in
+ * generate the secret key from it should use this class.
+ * Sometimes, such as when authenticating a server in
   * the absence of user-to-user authentication, the login module will  
store
   * an instance of this class in the private credential set of a
   * {@link javax.security.auth.Subject Subject} during the commit  
phase of the
   * authentication process.<p>
   *
+ * A Kerberos service using a keytab to read secret keys are advised  
to use
+ * the {@link KeyTab} class, where latest keys can be read at needed.
+ *

Compatibility risk: 	minimal

History
2010-01-03 21:16:21    	weijun.wang    	create
2010-01-03 21:42:17    	weijun.wang    	update

Thanks
Max

On Jan 13, 2010, at 11:08 PM, Mathieu Gervais (IDEAS) wrote:

> Hi Max,
>
> Is there a publicly accessible version of  http://ccc.sfbay.sun.com/6894072 
>  so we can review it as well?
> (is this the code, or a design document?)
>
> Thanks,
>
> -mathieu
>
>
> On Mon, Jan 4, 2010 at 15:00, <security-dev- 
> request at openjdk.java.net> wrote:
> Date: Mon, 04 Jan 2010 13:47:13 +0800
> From: "Max (Weijun) Wang" <Weijun.Wang at Sun.COM>
> Subject: [security-dev 01488]: Re: RFC: keytab automatic refresh in
>        Java
> To: OpenJDK Dev list <security-dev at openjdk.java.net>
> Cc: Nicolas Williams <Nicolas.Williams at Sun.COM>
> Message-ID: <A5CA49A9-E496-4A12-B600-B469E7594010 at sun.com>
> Content-Type: text/plain; CHARSET=US-ASCII; delsp=yes; format=flowed
>
> Hi
>
> Please take a review at the CCC:
>
>     http://ccc.sfbay.sun.com/6894072
>
> Thanks
> Max
>
> On Dec 22, 2009, at 12:25 PM, Max (Weijun) Wang wrote:
>
> > Hi All
> >
> > I'm planning to support keytab refresh in Java, which means the
> > keytab's content is always reloaded right after AP-REQ is received
> > on the acceptor side.
> >
> > One benefit is that when the service is started, the keytab file
> > needn't include the keys for the service, or, it can simply be non-
> > existent. More benefits are key refresh, key revocation, etc, etc.
> >
> > Currently, when useKeyTab is specified in the JAAS login config
> > file, if keys for the service name cannot be found inside the
> > keytab, JAAS automatically fallback to username/password prompt, and
> > if they cannot be provided, the login fails. In my plan, when keytab
> > refresh is supported, keytab will always be used even if it does not
> > exist, because there's a chance that it will contain the proper keys
> > later.
> >
> > So this introduces a behavior change, and I want to know how big the
> > risk is.
> >
> > Do you know if any customer relies on the current fallback? That is
> > to say, they manually config useKeyTab=true in the JAAS login
> > config, but (sometimes) does not provide a keytab file with correct
> > keys, and they expect username and password will be prompted for.
> >
> > The behavior change also means that if there is really something
> > wrong with the keytab config (say, wrong path name), currently an
> > app fails as soon as it starts, but with keytab refresh, it only
> > fails when AP-REQ is received.
> >
> > How does Solaris deal with keytab changes? Does it accept an empty
> > (or non-existent) keytab?
> >
> > Thanks
> > Max
> >
>
>
>
> End of security-dev Digest, Vol 31, Issue 1
> *******************************************