Last Call Review of draft-lha-gssapi-delegate-policy-
review-lha-gssapi-delegate-policy-secdir-lc-orman-2009-12-03-00

Request Review of draft-lha-gssapi-delegate-policy
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-12-08
Requested 2009-11-11
Authors Sam Hartman, Love Astrand
Draft last updated 2009-12-03
Completed reviews Secdir Last Call review of -?? by Hilarie Orman
Secdir Telechat review of -?? by Hilarie Orman
Assignment Reviewer Hilarie Orman
State Completed
Review review-lha-gssapi-delegate-policy-secdir-lc-orman-2009-12-03
Review completed: 2009-12-03

Review
review-lha-gssapi-delegate-policy-secdir-lc-orman-2009-12-03

Review of draft-lha-gssapi-delegate-policy-04

Do not be alarmed.  I have reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG. These comments were written primarily for
the benefit of the security area directors. Document editors and WG
chairs should treat these comments just like any other last call
comments.

The document describes an augmentation of the semantics of the GSSAPI
service delegation policy.  It allows a client to ask if there is a
policy allowing delegation of the service.

This is a something of a policy band-aid.  The API currently supports
only unconditional delegation.  This change allows a client to learn
if the local policy supports it.  The decision might involve tier of
Kerberos inter-realm servers, and the API is charged with enforcing
the policy of assuring that all tickets agree that delegation is
permitted.

The change is minimal, involving no over-the-wire changes, but I
imagine it is only part of the tip of a policy iceberg.  If clients
are to make policy decisions about something as complex as delegation,
ultimately they will need more specific information, I would imagine.
The security of the mechanism depends on how wise the administrators
are when configuring the delegation policy, but the clients have
no insight into how the decision was reached.  

I recommend that the security considerations section make some comment
about why a client would or would not make use of this new mechanism.
Perhaps it should be avoided for security-critical services ("don't
delegate, even if it is allowed")?  Or should it always be used?

-----------------------

Section 2.  Typo --- "to allow and administrator" should be "to allow
an administrator"

Section 4.  Grammar --- "If the initiator set both ... " should be
"sets".  Last paragraph "the the" should be "to the".  "There state"
should be "their state".

Section 5.  Grammar.
   When the initiator uses deleg_policy_req_flag, the GSS-API
   Kerberos mechanism, in addition to the service tickets' OK-AS-
   DELEGATE flag, the MUST examine all cross realm tickets in the
   traversal from the user's initial ticket-granting-ticket (TGT) to the
   service ticket.

Suggested rewording

   If the initiator sets the deleg_policy_req_flag, the GSS-API
   Kerberos mechanism MUST examine the OK-AS-DELEGATE flag in the
   service ticket, and it MUST examine all cross realm tickets in the
   traversal from the user's initial ticket-granting-ticket (TGT) to
   the service ticket.

Section 7.

   Failure to specify deleg_policy_req_flag on the part of the client
   can at worst result in NOT delegating credentials -- fails closed, a
   desirable security property.

Suggested rewording.

   A client's failure to specify deleg_policy_req_flag
   can at worst result in NOT delegating credentials.  This means
   that the client does not expand its trust, which is generally safer
   than the alternative.