A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism
draft-ietf-kitten-rfc4402bis-02

[Ballot comment]
There is one thing I'd like to discuss here (lower-case "discuss"):

  This document obsoletes RFC 4402 and reclassifies that document as
  historic.

We don't have a clear sense of what "historic" means and how it interacts with "obsolete", so let me start with how I look at it:
I think that a newer version of a protocol specification makes the old version of that protocol obsolete.
I think that a protocol (but not a version) that is no longer recommended for use might become historic.
I think that if we have a protocol called ABCDP, and we make a new protocol called LMNOP that replaces ABCDP, we might likely make ABCDP historic.
I think that if we then have an updated version of LMNOP, that obsoletes the earlier version... but it doesn't make it historic.

So I question whether the "reclassifies as historic" is the right thing here or not.  4402 will be marked "obsolete", and that should be enough.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-kitten-rfc4402bis-01.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

IANA notes that the authors suggest that: "If and when a relevant IANA registry of GSS-API symbols and constants is created, then the GSS_KRB5_S_KG_INPUT_TOO_LONG minor status code should be added to such a registry." IANA understands this as a reminder to future authors of such a draft and not as an action for IANA to complete.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: kitten-chairs@ietf.org, draft-ietf-kitten-rfc4402bis@ietf.org, "Benjamin Kaduk" , kitten@ietf.org, kaduk@mit.edu, stephen.farrell@cs.tcd.ie
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism) to Proposed Standard


The IESG has received a request from the Common Authentication Technology
Next Generation WG (kitten) to consider the following document:
- 'A Pseudo-Random Function (PRF) for the Kerberos V Generic Security
  Service Application Program Interface (GSS-API) Mechanism'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-12-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines the Pseudo-Random Function (PRF) for the
  Kerberos V mechanism for the Generic Security Service Application
  Program Interface (GSS-API), based on the PRF defined for the
  Kerberos V cryptographic framework, for keying application protocols
  given an established Kerberos V GSS-API security context.

  This document obsoletes RFC 4402 and reclassifies that document as
  historic.  RFC 4402 starts the PRF+ counter at 1, however a number of
  implementations starts the counter at 0.  As a result, the original
  specification would not be interoperable with existing
  implementations.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-kitten-rfc4402bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-kitten-rfc4402bis/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

Benjamin Kaduk is the document shepherd.  Stephen Farrell is the
responsible Area Director.

This document is necessary because implementors of RFC 4402 erred
when implementing the PRF+ construct, starting the counter variable
at zero instead of one.  The error was present in multiple releases
of a shipping implementation when a second implementor discovered
the error in interoperability testing; that second implementor also
started the counter variable at zero for compatibility.  This document
serves to update RFC 4402 and reflect the implementation reality
that is deployed and functioning interoperably.  It is being published
as a Standards Track document to match RFC 4402 which it replaces,
as is consistent with most work on Kerberos in the IETF.


2. Review and Consensus

There is strong consensus for this document, which only differs from
RFC 4402 in the change of the initial value of the counter variable
and the removal of an unneeded and confusing paragraph from the
security considerations section.  It also adds test vectors, which
have been verified by two implementations (MIT and Heimdal Kerberos).
The WGLC period was part of a combined WGLC for three "bis" documents,
over a period of four weeks.  Most of the prominent WG contributors
reviewed the document, and no substantive issues were found (though
a couple of regressions from RFC 4402 were noted and fixed).


3. Intellectual Property

There are no intellectual property disclosures against this document,
and both authors have confirmed conformance with BCPs 78 and 79.


4. Other Points

There are no downrefs and no IANA considerations (since there is no
IANA registry for the GSS-API namespace or error codes specified
in the document).  The document is a little old (some 200-odd days,
as noted by idnits), due to the shepherd being preoccupied due to
moving residences and employment.

There is one erratum against RFC 4402, the issue that this document
is intended to resolve.