Services4User review

[Luke Howard]

Hi Nico,

> 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.

I'm not sure if I understand this: could you point me to where in [MS- 
SFU] it says that delegation is specified in the authorization data of  
the initiator's service ticket?

> 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.

In practice I'm not sure if this is a big issue. In the current  
implementation unconstrained delegation (ie. forwarded credentials)  
take precedence.

> - 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.

Note we don't have gss_store_cred() yet.

> - 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".

Where does one specify the service to which to delegate to? Would that  
be another input?

> - 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".

OK, this looks reasonable.

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


I'm not sure, but I think for 1.8 I'd prefer to expose at GSS-API  
first, and then for a future release we can think about exposing the  
underlying krb5 APIs. I don't feel too strongly about this though.

How do others feel about this? The proposed changes seem reasonable to  
me. One change is that I was initially planning to make these  
mechanism-specific APIs; do we want to commit to introducing new  
mechanism-agnostic APIs?

cheers,

-- Luke