[secdir] Review of draft-lha-gssapi-delegate-policy-04

"Hilarie Orman" <hilarie@purplestreak.com> Tue, 01 December 2009 02:19 UTC

Return-Path: <hilarie@purplestreak.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 7B7613A6A04; Mon, 30 Nov 2009 18:19:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id AG05Jw87Ob9t; Mon, 30 Nov 2009 18:19:28 -0800 (PST)
Received: from out01.mta.xmission.com (out01.mta.xmission.com []) by core3.amsl.com (Postfix) with ESMTP id 9B5D73A6405; Mon, 30 Nov 2009 18:19:28 -0800 (PST)
Received: from mx01.mta.xmission.com ([]) by out01.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <hilarie@purplestreak.com>) id 1NFIWJ-0004Gj-Df; Mon, 30 Nov 2009 19:31:15 -0700
Received: from 166-70-57-249.ip.xmission.com ([] helo=fermat.rhmr.com) by mx01.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <hilarie@purplestreak.com>) id 1NFIKl-0001Cv-7H; Mon, 30 Nov 2009 19:19:20 -0700
Received: from fermat.rhmr.com (localhost []) by fermat.rhmr.com (8.14.3/8.14.3/Debian-6) with ESMTP id nB12IwCd022304; Mon, 30 Nov 2009 19:18:58 -0700
Received: (from ho@localhost) by fermat.rhmr.com (8.14.3/8.14.3/Submit) id nB12IvHB022301; Mon, 30 Nov 2009 19:18:57 -0700
Date: Mon, 30 Nov 2009 19:18:57 -0700
Message-Id: <200912010218.nB12IvHB022301@fermat.rhmr.com>
X-Authentication-Warning: fermat.rhmr.com: ho set sender to hilarie using -f
From: "Hilarie Orman" <hilarie@purplestreak.com>
To: secdir@ietf.org
X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx01.mta.xmission.com; ; ; ip=; ; ; frm=hilarie@purplestreak.com; ; ; spf=none
X-XM-DomainKey: sender_domain=purplestreak.com; ; ; sender=hilarie@purplestreak.com; ; ; status=error
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa03 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: ;secdir@ietf.org
X-SA-Exim-Version: 4.2.1 (built Thu, 25 Oct 2007 00:26:12 +0000)
X-SA-Exim-Scanned: Yes (on mx01.mta.xmission.com)
Cc: hartmans-ietf@mit.edu, lha@apple.com, iesg@ietf.org
Subject: [secdir] Review of draft-lha-gssapi-delegate-policy-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Hilarie Orman <hilarie@purplestreak.com>
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Dec 2009 02:19:29 -0000

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

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

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.