Subject: [secdir] SecDir review of draft-ietf-krb-wg-gss-cb-hash-agility-08

From: <[email-masked]>
Date: Mon, 28 Nov 2011 14:53:56 -0500

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.

Description: This document updates RFC4121<http://tools.ietf.org/html/rfc4121> to allow channel bindings using algorithms negotiated based on Kerberos crypto framework as defined in RFC3961<http://tools.ietf.org/html/rfc3961>.  In addition, because this update makes use of the last extensible field in the Kerberos client-server exchange message, extensions are defined to allow future protocol extensions.

I think the document is ready.  The only suggestion would be to consider expanding out the security consideration section to list any risks with using or not using channel bindings.  Right now, it states it is up to the application's policy, which is fine, but may leave developers with questions.

Telechat is on 12-30-2011

Thank you,
Kathleen

---

From: Nico Williams <[email-masked]>
Date: Mon, 28 Nov 2011 14:13:44 -0600

> I think the document is ready.  The only suggestion would be to consider expanding out the security consideration section to list any risks with using or not using channel bindings.  Right now, it…

This document is not really of interest to GSS-API application
protocol developers -- they should be using RFCs 2743 and 5554.  This
doc is intended primarily for Kerberos GSS mechanism implementors.

That said, informative references to RFC 5056 and 5554 wouldn't hurt,
and in any case I'm not opposed to the proposed change.

Nico
--

---

From: Shawn Emery <[email-masked]>
Date: Mon, 28 Nov 2011 23:38:17 -0700

On 11/28/11 01:13 PM, Nico Williams wrote:
> On Mon, Nov 28, 2011 at 1:53 PM,<[email-masked]>  wrote:

Perhaps I should mention something like this in the sec cons section and 
remove the second paragraph?

> and in any case I'm not opposed to the proposed change.

See above.

Shawn.
--