RX Kerberos 5 security class requirements of Kerberos library

[Jeffrey Altman]

Marcus Watts wrote:
> Sam Hartman <hartmans at mit.edu> writes:
>>>>>>> "Marcus" == Marcus Watts <mdw at umich.edu> writes:
>>     Marcus> I hope that answer's Sam's concerns regarding not going
>>     Marcus> through the KDC for this code path.
>>
>> Not entirely.  I definitely think that when there is a KDC available
>> that you should use it.  I'm willing to accept that you might want a
>> fallback for talking to local services when you have a key and no
>> network.
>>
>> --Sam
> 
> Ok.  Let's talk about that.  How does the AFS "server-side" client code
> know when the KDC is up?  What value is the KDC going to add in
> participating in this process?  What use is another AFS server going to
> put in whatever might be provided by the KDC that couldn't be
> constructed directly by the remote server?  How can that AFS server
> know that any such added data was in fact authentic secure data added
> by the KDC and not just something made up by another server with access
> to the service key?  I can think of a lot of interesting things that
> might be done by some future KDC (though not very many that present
> KDC's do) -- but I can't think of any that are relevant to -localauth.

The AFS folks are thinking primarily about how AFS works today in the
legacy of kaserver and how can we easily implement -localauth based
upon that architecture.

Sam and Nico are considering other possibilities.  For one, there
are uses for such an API for non-local auth uses.  Think of Love's
forging of AFS user tokens by Samba.  This is not a local auth operation
and it could very well benefit from contact with the KDC.

You example of ptserver is perfect for this discussion.

> Just to make life a bit interesting: here's something else to
> consider.  For AFS, the most *useful* value the KDC could add in the
> future would be to do an AFS "GetCPS" call and fill in a list of groups
> that the user belongs to, and construct an AFS PAC in the ticket it
> returns.  That means talking to ptserver in order to do this.  How
> should this interact with "bos start <host> ptserver -localauth"?

Imagine the AFS protection database and the Kerberos database stored
within the same LDAP backend.  When issuing an AFS service ticket it
would make perfect sense for the KDC to obtain the PTS group memberships
from its local instance of the Protection Service and store them within
the authorization data.

In the Samba scenario, it would make perfect sense for this to be the
behavior.

Another UMich scenario is KX509.  After authenticating the user via TLS
the server needs to construct Kerberos 5 ticket for the backend service.
 You really want this ticket to contain whatever authorization data
would have been inserted by the KDC.  We might also want to store the
X509 certificate in the ticket as authorization data itself.

The requirement that Sam has imposed is that the resulting function
prototype be general enough to support more than just the -localauth
case because AFS is the only application service for which we can think
that we would approve of its use.

> Some other cases besides "key and no network" are "network and no kdc"
> and "partitioned network".  These might occur during either planned
> (installation, routine maintenance) or unplanned (something gets sick)
> activities.

My revised prototype looks like this:

  krb5_error_code KRB5_CALLCONV
  krb5_generate_creds_with_keytab(
      krb5_context context,
      krb5_principal client,
      krb5_keytab    client_keytab,
      krb5_principal service,
      krb5_keytab    service_keytab,
      time_t starttime,
      time_t endtime,
      krb5_enctype  *allowed_enctypes,
      krb5_address  *address,		/* optional */
      krb5_data      authz_data,	/* optional */
      krb5_flags     flags,
      krb5_creds** out_creds /* out */ )

where for AFS client_keytab and service_keytab would be the same until
AFS starts to support separate service keys, and the authz_data would
be empty.

One flag that could be specified is KRB5_GENCREDS_AFS_LOCALAUTH which
allows us to indicate that AFS -localauth is being used and ensures that
(a) it is not the default behavior
(b) permits AFS to make use of the other functionality in the future.

Jeffrey Altman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20070103/3e7e7930/attachment.bin