Last Call Review of draft-ietf-kitten-rfc5653bis-05
review-ietf-kitten-rfc5653bis-05-secdir-lc-polk-2017-11-18-00

Request Review of draft-ietf-kitten-rfc5653bis
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-09-11
Requested 2017-08-28
Other Reviews Opsdir Last Call review of -05 by Joe Clarke (diff)
Genart Last Call review of -05 by Joel Halpern (diff)
Genart Telechat review of -06 by Joel Halpern
Review State Completed
Reviewer Tim Polk
Review review-ietf-kitten-rfc5653bis-05-secdir-lc-polk-2017-11-18
Posted at https://mailarchive.ietf.org/arch/msg/secdir/0zt_zsyzjSSy-RP-6wZwdhHp8PI
Reviewed rev. 05 (document currently at 06)
Review result Ready
Draft last updated 2017-11-18
Review completed: 2017-11-18

Review
review-ietf-kitten-rfc5653bis-05-secdir-lc-polk-2017-11-18

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.

The summary of the review is Ready.

This document is a straightforward update of RFC 5653:

1. The draft modifies GSSException to support an embedded error token; as
specified in RFC 5653 a JGSS application throwing a GSSException could
not return an error token, a functional shortcoming in comparison with
the C bindings of GSS-API (see RFC 2744). The embedded error token
corrects this shortcoming. The document describes a compatibility strategy
for new JGSS programs that run with both RFC5653 and RFC5653bis Java
bindings.

2. The draft removes stream-based GSSContext methods.  These methods
cannot be implemented correctly where tokens have no self-framing or the
library has no knowledge of the token format.  The document states that
applications using input and output streams as the means to convey
authentication and per-message GSS-API tokens should also define the wire
protocol.  The reviewer infers that new applications using this design
strategy should be compatible with RFC5653 bindings, but that is not
explicitly stated.