Subject: 
        RE: GGF's extensions to GSS in Public Comment
   Date: 
        Fri, 9 Apr 2004 13:10:38 -0400
   From: 
        "Linn, John" <jlinn@rsasecurity.com>
     To: 
        "'Russ Housley'" <housley@vigilsec.com>
    CC: 
        "'brc@zurich.ibm.com'" <brc@zurich.ibm.com>




Per Russ' request, I've now given this document an initial review.  I was
the editor of RFC-2743, which this draft proposes to extend, and respect the
goals that its authors have sought to achieve.  Several of its facilities
may comprise useful, optional capabilities to be considered as extensions to
the base GSS-API.  I'm concerned, however, about some of the specifics as
proposed.   Here are some thoughts.

Regarding credential export and import, this may be a useful added facility
for cases where implementation characteristics and security policies permit.
>From the description provided for gss_export_cred, however, it's unclear to
me why the "option_req" choice between serializing credential data into a
GSS-importable form vs. a mechanism-specific form is necessary, how various
forms of the latter type might be requested or discriminated from one
another, or which choice would be preferable under which circumstances.  Why
not uniformly export to the form that the proposed gss_import_cred can
import, and define separate routines (likely environment-specific), outside
the scope of the extended GSS-API, that can then import from that format?  

The proposal seeks to significantly extend delegation management relative to
that provided in RFC-2743, where delegation of credentials can only be
performed from security context initiator to context target, and only in
conjunction with the context establishment process.  Effectively, the
proposal would leverage a security context, once established, as a means to
exchange and delegate arbitrary credentials in either direction.  Other
proposed facilities suggest that credentials may be annotated with various
authorization attributes in extensions.  Given this, I'm concerned from both
security and complexity perspectives that it may be difficult to determine
precisely what privilege context should be associated with a security
context and its associated actions at different points during its lifetime.
If credential sets (and their associated rights) are to change dynamically
following a context establishment, and hence during a session, it would
appear symmetric to provide a means to deactivate a previously-granted
delegation, a facility which doesn't seem to be supported.  It's also
unclear to me how a delegation target is to determine that a delegation is
incoming and, hence, when to pass a received token to the proposed
gss_accept_delegation interface.  Given these concerns, I'm not sure that
it's necessarily worth the optimization of delegating credentials within an
established context rather than simply creating a new context and reusing
the existing delegate-at-establishment facility.  

The authors cite an additional goal of delegating credentials for a
different mechanism than that with which the context was originally
established; this is an appealing idea, but may not be securely feasible
with arbitrary combinations of mechanisms.  For gss_init_delegation and
gss_accept_delegation, the proposal reinterprets the GSS-defined meaning of
GSS_S_BAD_BINDINGS, which was intended to detect channel binding mismatches
upon context establishment.  Secure delegation may require that an
authentication operation be performed using the delegated credentials and
mechanism (as the current delegate-at-establishment facility may do at
context establishment time).  Channel bindings might be relevant here as
well, and the status code redefinition seems to mask this prospect. 

The Extended Credential Inquiry section (which, given its content, should
perhaps be retitled Extended Credential and Context Inquiry?) seems to
define useful hooks for obtaining various attributes with which...