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-
[email protected]> wrote:
Date: Mon, 04 Jan 2010 13:47:13 +0800
From: "Max (Weijun) Wang" <[email protected]>
Subject: [security-dev 01488]: Re: RFC: keytab automatic refresh in
Java
To: OpenJDK Dev list <[email protected]>
Cc: Nicolas Williams <[email protected]>
Message-ID: <[email protected]>
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
*******************************************
