Services4User review

[Nicolas Williams]

On Tue, Aug 18, 2009 at 03:24:25PM +0200, Luke Howard wrote:
> I'd love some feedback on the S4U2{Self,Proxy} design at:
> 
> 	http://k5wiki.kerberos.org/wiki/Projects/Services4User
> 
> (particularly the "Open Issues" section)

The description of the GSS functions is not enough for me to understand
them.  But in any case, I see both of these as credential
handle-centric, not security context-centric.

So I would propose GSS extensions for obtaining S4U2Proxy credentials
handles from delegated credential handles returned by
GSS_Accept_sec_context().

Delegated credential handles need not correspond to delegated
credentials in the RFC1964/4121 sense, nor should it be necessary that
the caller of GSS_Init_sec_context() have explicitly requested
credential delegation -- in the S4U2{Self,Proxy} the delegation is
specified in the authz-data of the initiator's service Ticket, and the
decision to delegate could be made by the KDC.

One wrinkle: is it OK for GSS_Accept_sec_context() to return delegated
credentials when the initiator did not explicitly request it but the
mechanism either does it by its own nature (e.g., LIPKEY) or a third
part forces it (e.g., a KDC with S4U2Proxy support)?  IMO yes, it would
be, but see below.  However, others might disagree, and that's the only
case in which I think we might need a security context-specific
extensions: to allow the acceptor to accept S4U2Proxy creds, and to
allow traditional delegated creds and S4U2Proxy creds to be separated.

Another wrinkle: what if a client does delegate a credential in the
RFC1964/4121 sense _and_ its KDC does the S4U2Proxy thing?  If you call
GSS_Store_cred() on the delegated credential handle you'd lose the
S4U2Proxy component in existing implementations.  But this is a local
matter, easily fixed.

My proposal:

 - Let gss_accept_sec_context() always output a delegated cred handle in
   the krb5 case, even when there's no traditional credential delegation
   on the part of the initiator.  Let gss_store_cred() fail if there's
   no traditional "forwarded Ticket" in the delegated credential.

 - For S4U2Proxy add gss_acquire_cred_impersonate_deleg() with two
   credential handle inputs:

    - service_cred_handle (the caller's own cred handle)
    - subject_cred_handle (the delegated credential whose subject is to
      be impersonated)

   and let it output a new cred handle corresponding to "the subject as
   impersonated by the service".

 - For S4U2Self add gss_acquire_cred_impersonate() with these inputs:

    - desired_subject_name (the name of the subject to impersonate)
    - input_cred_handle (the service's own credentials)
    - desired_cred_usage (the type of desired credentials)
    - desired_mechs (set of mechanism OIDs for which creds are desired)
    - time_req (requested credential lifetime)

   and which outputs a new cred handle corresponding to the "the desired
   subject as impersonated by the service".

Also, are you sure that there are no non-GSS-API applications where
S4U2{self,Proxy} might be needed?

Nico
--