[secdir] secdir review of draft-yount-krb-cred-clear-text-01.txt

Warren Kumari <warren@kumari.net> Tue, 09 August 2011 03:06 UTC

Return-Path: <warren@kumari.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953E211E808F; Mon, 8 Aug 2011 20:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OteLJ7j7UFb7; Mon, 8 Aug 2011 20:06:38 -0700 (PDT)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED2211E8070; Mon, 8 Aug 2011 20:06:37 -0700 (PDT)
Received: from [192.168.1.4] (24-104-73-2-ip-static.hfc.comcastbusiness.net [24.104.73.2]) by vimes.kumari.net (Postfix) with ESMTPSA id 3ED961B40CC6; Mon, 8 Aug 2011 23:07:04 -0400 (EDT)
From: Warren Kumari <warren@kumari.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 08 Aug 2011 20:07:02 -0700
Message-Id: <EBDDC31C-A2D0-4FF5-8EE8-D7061EA23805@kumari.net>
To: secdir@ietf.org, iesg@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Cc: draft-yount-krb-cred-clear-text.all@tools.ietf.org
Subject: [secdir] secdir review of draft-yount-krb-cred-clear-text-01.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Aug 2011 03:06:38 -0000

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.

This document formalizes the unencrypted form of the KRB-CRED message.

I am not a Kerberos expert (nor do I play one on TV) so this review is going to have limited value.

I am unclear as to whether there is a need for this facility -- there could be additional explanation and justification for why this is needed. Assuming that there is a need for this, the document seems well written.

The Security Considerations section outlines risks incurred by not having encryption, and specifies that this must only be used with a transport such as TLS that provides integrity and confidentiality. What is unclear from the security considerations section is that this transport must provide end to end security -- for example an IPSec VPN provides "a transport where sender and recipient identities can been established be known to each other and provides confidentiality and integrity.", but presumably the intent is that the encryption be between the applications -- IMO this should be clarified. 

I feel that there should advice provided regarding under what conditions use of this is appropriate -- but, than again, maybe this is obvious to someone who actually understands Kerberos :-P

Nit:
Section 3:
  s/MUST BE/MUST be/

W