[secdir] Secdir review of draft-ietf-kitten-rfc2853bis-05.txt (GSSAPI JAVA BINDINGS)

Charlie Kaufman <charliek@microsoft.com> Sun, 31 May 2009 06:18 UTC

Return-Path: <charliek@microsoft.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 879693A698D; Sat, 30 May 2009 23:18:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.098
X-Spam-Level:
X-Spam-Status: No, score=-11.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyjQau5PLbSq; Sat, 30 May 2009 23:18:38 -0700 (PDT)
Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id B2CBD3A6912; Sat, 30 May 2009 23:18:38 -0700 (PDT)
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Sat, 30 May 2009 23:20:23 -0700
Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([157.54.97.142]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi; Sat, 30 May 2009 23:20:22 -0700
From: Charlie Kaufman <charliek@microsoft.com>
To: "'secdir@ietf.org'" <secdir@ietf.org>, "'iesg@ietf.org'" <iesg@ietf.org>, "mayank+ietf-2853@google.com" <mayank+ietf-2853@google.com>, "seema.malkani@sun.com" <seema.malkani@sun.com>, "shawn.emery@sun.com" <shawn.emery@sun.com>, "tlyu@mit.edu" <tlyu@mit.edu>
Thread-Topic: Secdir review of draft-ietf-kitten-rfc2853bis-05.txt (GSSAPI JAVA BINDINGS)
Thread-Index: Acnht+KgOQmkN2JhRZyaHaEt2kieOQ==
Date: Sun, 31 May 2009 06:20:25 +0000
Message-ID: <D80EDFF2AD83E648BD1164257B9B091201E883@TK5EX14MBXC117.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_D80EDFF2AD83E648BD1164257B9B091201E883TK5EX14MBXC117red_"
MIME-Version: 1.0
Subject: [secdir] Secdir review of draft-ietf-kitten-rfc2853bis-05.txt (GSSAPI JAVA BINDINGS)
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: Sun, 31 May 2009 06:18:39 -0000

I am reviewing 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. Feel free to forward to any appropriate forum.

This refresh of RFC 2853 (GSSAPI JAVA BINDINGS) is almost trivial. The only technical changes are the renumbering of error codes and OID values because the values in RFC 2853 were internally inconsistent, missing, or (in the case of OIDs) obsolete. There are a handful of other minor corrections in the document (none technical). The document was also refreshed to use the now-current copyright notices, etc.

Since all of the error codes correspond to fatal errors, it is unlikely that even interoperation with an implementation with bad codes could cause security problems (just confusing error messages). The security considerations seemed reasonable in RFC 2853 and they are unchanged here.

                --Charlie