[secdir] Re-review of draft-lha-gssapi-delegate-policy-04

"Hilarie Orman" <ho@alum.mit.edu> Sat, 27 February 2010 23:55 UTC

Date: Sat, 27 Feb 2010 16:54:03 -0700
Message-Id: <201002272354.o1RNs3J9021727@fermat.rhmr.com>
From: Hilarie Orman <ho@alum.mit.edu>
To: secdir@ietf.org, iesg@ietf.org
Cc: hartmans-ietf@mit.edu, lha@apple.com
Subject: [secdir] Re-review of draft-lha-gssapi-delegate-policy-04
Precedence: list
Reply-To: Hilarie Orman <ho@alum.mit.edu>

The draft, including typos, is unchanged since my review 3 months ago.

Hilarie

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

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 a central server
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 a
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.

[secdir] Re-review of draft-lha-gssapi-delegate-p… Hilarie Orman