[secdir] Secdir review of draft-josefsson-kerberos5-starttls-07

Magnus Nyström <magnusn@gmail.com> Thu, 24 December 2009 01:23 UTC

Return-Path: <magnusn@gmail.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 E27743A687F; Wed, 23 Dec 2009 17:23:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id FNkeT8MC+ky9; Wed, 23 Dec 2009 17:23:49 -0800 (PST)
Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com []) by core3.amsl.com (Postfix) with ESMTP id EB0923A6873; Wed, 23 Dec 2009 17:23:48 -0800 (PST)
Received: by ywh15 with SMTP id 15so8001230ywh.5 for <multiple recipients>; Wed, 23 Dec 2009 17:23:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=tUTzQzOTqBzBpdZsyW0vyPJplKe4/KMMfmfhhAJrjkw=; b=tOWL6KbfIEzMC51KlqffhkbGvTIBGLjGv269//iP94PSd4vrOwQchFNC5JA1outQ1j QhYt37ioRRsw04a7LmW+im0dDSDWC0DK+wFEmc7uEsxlL9sAfMVrqUHoZ01jtKsAij1D ViKIVL+1w52uoFZNMJOxCkwPL+lOjWHKnNHmw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=Wk8WZNLerV1RxG7uG8lRL9oqJO1N9SieVEVvSL7SZ29SNZMGirSZTvYFJxn0Wbnmx+ 70W4nDVoCqpCNEBXvk/THo3LkGru+7YsedVLNAmJX6nDIXs+khs1F9oLXbOJ6oFPZDvY qtvBJ+IlxjE0daQ8FnEXX5VGaLSma0p97YJ0U=
MIME-Version: 1.0
Received: by with SMTP id j22mr5809700ann.6.1261617809211; Wed, 23 Dec 2009 17:23:29 -0800 (PST)
Date: Wed, 23 Dec 2009 17:23:29 -0800
Message-ID: <2f57b9e60912231723x12e87864g9c0ad1ce095fc2c2@mail.gmail.com>
From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= <magnusn@gmail.com>
To: iesg@ietf.org, secdir@ietf.org, simon@josefsson.org, larry.zhu@microsoft.com, jhutz@cmu.edu
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: [secdir] Secdir review of draft-josefsson-kerberos5-starttls-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Thu, 24 Dec 2009 01:25:26 -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 defines a new Kerberos extension to allow Kerberos
protocol runs over TLS.

I do not have any general issues with this document but a few

Section 1: "The TLS protocol has been studied by many parties.  In
some threat models, the designer prefer to reduce the number of
protocols that can hurt the overall system security if they are
compromised." This statement seems to me like a strange reason to
motivate this work - Kerberos is equally well studied (at least) as
TLS and this memo does not reduce the number of protocols in the
system (c.f. the recent TLS renegotiation vulnerability)

Section 3: In the packet flow, why are the first two Kerberos
exchanges ([0x70000000 & STARTTLS-bit] and [0x00000000]) wihtin square
brackets? Is it because they're seen as a separate protocol, or some
other reason? A clarification would be helpful.

Section 5: "Use of TLS, even without server certificate validation,
protects against some attacks that Kerberos V5 over UDP/TCP do not.
Requiring server certificates to be used at all times would enable
attacks in those situations": a) It would be useful to give examples
of attacks that unauthenticated TLS protects against that Kerberos V5
does not protect against. b) Last sentence is ambigious - if server
certs are required and the client verifies them I do not see what
attacks would be enabled. I assume the last sentence intends to say
that requiring server certs to be used when clients cannot validate
will enable some attacks but I am not sure.

Section 5: "When clients have the ability, they need to be able to
validate the server certificate" I suggest rephrasing to: "When
clients have the ability, they MUST validate the server certificate"
(or at least SHOULD).

-- Magnus