Request for Comment: Multiple service name support in JGSS/SASL with krb5 as a mechanism

[Weijun Wang]

Hi Valerie

Currently, a Kerberos (in JGSS or SASL) service must know the exact 
service name it is serving with (say, http/my.host.com). This is not 
true any more in today's virtualized world in which a service might be 
serving clients from different networks by exposing different service names.

This is similar to the TLS SNI extension, where different clients 
accessing the same server with different names. In the case of TLS, the 
server needs to find different certificates to send back the client, in 
Kerberos, the server needs to use different keys to decipher the service 
ticket.

In today's JAAS, JGSS or SASL design:

1. In JAAS, you must setup a principal value for Krb5LoginModule, 
normally in the JAAS login file. Without the principal, Krb5LoginModule 
does not know what keys to load from a keytab file.

2. In JGSS, the chance is little better, the service GSSContext is 
created with

     GSSManager.createContext(GSSCredential myCred)

Here the myCred can be null so that the credential can be decided by the 
Krb5LoginModule.

3. In SASL, when creating SaslClient or SaslServer [1], the protocol and 
serverName must be supplied non-null to create a GSSName with the form

     service at serverName

In order to support multiple service names, we need to make some 
changes. First, this is the glossary I'm going to use:

    a concrete name: http/my.host.com
    a half-concrete name: http/*
    a wild name: *

Here are the proposed changes:

1. In JAAS config file, the principal can be non-concrete, which means 
when a keytab is loaded, any key inside it might be used later. To be 
backward compatible, a principal value still must be provided. 
Otherwise, a NameCallback might be triggered.

2. In SASL, the serverName on the SaslServer side can be missing, which 
means it's willing to accept connections with any hostname to this 
service. Normally, the service should still be specified, and the result 
is a half-concrete name: "http/*" in Kerberos.

3. This means in JGSS, we need to support GSSCredential with a 
half-concrete GSSName. For example, the GSSName "http@*" means a connect 
to any host is allowed, as long as the service is http.

1'. Back to JAAS, We'll also allow this half-concrete name in JAAS 
config file.

What we are not going to support or at least not documented:

1. More liberal host name, say, http/*.host.com

2. Multiple service support in SASL, say, */my.host.com.

After these changes, the choice of a final concrete Kerberos service 
principal name is an intersection of three filters:

1. The principal in JAAS config
2. The myCred when creating a service GSSContext
3. The peer requested by the initiator

The calculated result should be a concrete principal name. This can be 
guaranteed since #3 above is already concrete.

If there is already a conflict between 1 and 2, the service can refuse 
to launch at all.

Note: in the TLS krb5 ciphersuite, the #3 above is not concrete because 
the server does not know what service principal is. There are 2 
workarounds for this:

1. Get the princ name from the SNI extension or some other 
Kerberos-specified extension

2. The JAAS config file already provides a concrete principal.

Thanks
Max

[1] 
http://download.oracle.com/javase/7/docs/api/javax/security/sasl/Sasl.html