< draft-ietf-kitten-kerberos-iana-registries-03.txt		draft-ietf-kitten-kerberos-iana-registries-04.txt >
	Network Working Group T. Yu		Network Working Group T. Yu
	Internet-Draft MIT Kerberos Consortium		Internet-Draft MIT Kerberos Consortium
	Updates: rfc4120 (if approved) February 14, 2014		Updates: rfc4120 (if approved) March 30, 2017
	Intended status: Standards Track		Intended status: Standards Track
	Expires: August 18, 2014		Expires: October 1, 2017
	Move Kerberos protocol parameter registries to IANA		Move Kerberos protocol parameter registries to IANA
	draft-ietf-kitten-kerberos-iana-registries-03		draft-ietf-kitten-kerberos-iana-registries-04
	Abstract		Abstract
	The Keberos 5 network authentication protocol has several numeric		The Keberos 5 network authentication protocol has several numeric
	protocol parameters. Most of these parameters are not currently		protocol parameters. Most of these parameters are not currently
	under IANA maintenance. This document requests that IANA take over		under IANA maintenance. This document requests that IANA take over
	the maintenance of the remainder of these Kerberos parameters.		the maintenance of the remainder of these Kerberos parameters.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 18, 2014.		This Internet-Draft will expire on October 1, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 7, line 8 ¶		skipping to change at page 7, line 13 ¶
	MUST be Standards Action.		MUST be Standards Action.
	Protocol version number (pvno) values will not be registered. The		Protocol version number (pvno) values will not be registered. The
	location of the "pvno" value in Kerberos messages is not in a place		location of the "pvno" value in Kerberos messages is not in a place
	that implementations can meaningfully use to distinguish among		that implementations can meaningfully use to distinguish among
	different variants of the Kerberos protocol.		different variants of the Kerberos protocol.
	8. Contributors		8. Contributors
	Sam Hartman proposed the text of the expert review guidelines. Love		Sam Hartman proposed the text of the expert review guidelines. Love
	Hornquist Astrand wrote a previous document		Hornquist Astrand wrote a previous document (draft-lha-krb-wg-some-
	(draft-lha-krb-wg-some-numbers-to-iana-00) with the same goals as		numbers-to-iana-00) with the same goals as this document.
	this document.
	9. Acknowledgments		9. Acknowledgments
	Thanks to Tom Petch for providing useful feedback on previous		Thanks to Tom Petch for providing useful feedback on previous
	versions of this document.		versions of this document.
	10. Security Considerations		10. Security Considerations
	Assignments of new Keberos protocol parameter values can have		Assignments of new Keberos protocol parameter values can have
	security implications. In cases where the assignment policy calls		security implications. In cases where the assignment policy calls
	skipping to change at page 7, line 31 ¶		skipping to change at page 7, line 35 ¶
	for expert review, the reviewer is responsible for evaluating whether		for expert review, the reviewer is responsible for evaluating whether
	adequate documentation exists concerning the security considerations		adequate documentation exists concerning the security considerations
	for the requested assignment. For assignments that require IETF		for the requested assignment. For assignments that require IETF
	review or standards action, the normal IETF processes ensure adequate		review or standards action, the normal IETF processes ensure adequate
	treatment of security considerations.		treatment of security considerations.
	11. IANA Considerations		11. IANA Considerations
	This document requests that IANA create several registries for		This document requests that IANA create several registries for
	Kebreros protocol parameters:		Kebreros protocol parameters:
	o Address types		o Address types
	o Authorization data types		o Authorization data types
	o Error codes		o Error codes
	o Key usages		o Key usages
	o Name types		o Name types
	o AP-REQ options		o AP-REQ options
	o KDC-REQ options		o KDC-REQ options
	o Ticket flags
			o Ticket flags
	This document requests that IANA modify the existing "Pre-		This document requests that IANA modify the existing "Pre-
	authentication data and typed data" registry to contain an additional		authentication data and typed data" registry to contain an additional
	reference to this document, and to transform existing names in that		reference to this document, and to transform existing names in that
	registry to the lowercase-and-hyphens style.		registry to the lowercase-and-hyphens style.
	12. Open issues		12. Open issues
	Do we make a registry for application tag numbers (equal to message		Do we make a registry for application tag numbers (equal to message
	type numbers)? We've said that we would replace the entire ASN.1		type numbers)? We've said that we would replace the entire ASN.1
	module in that case, but Nico's recent proposal doesn't do that, and		module in that case, but Nico's recent proposal doesn't do that, and
	skipping to change at page 8, line 17 ¶		skipping to change at page 8, line 26 ¶
	for registrations.)		for registrations.)
	Do transited encodings need a registry? They would probably require		Do transited encodings need a registry? They would probably require
	standards action, even if there were a registry.		standards action, even if there were a registry.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for		[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
	Kerberos 5", RFC 3961, February 2005.		Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February
			2005, <http://www.rfc-editor.org/info/rfc3961>.
	[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The		[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
	Kerberos Network Authentication Service (V5)", RFC 4120,		Kerberos Network Authentication Service (V5)", RFC 4120,
	July 2005.		DOI 10.17487/RFC4120, July 2005,
			<http://www.rfc-editor.org/info/rfc4120>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		DOI 10.17487/RFC5226, May 2008,
			<http://www.rfc-editor.org/info/rfc5226>.
	13.2. Informative References		13.2. Informative References
	[RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network		[RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network
	Authentication Service (V5)", RFC 1510, September 1993.		Authentication Service (V5)", RFC 1510,
			DOI 10.17487/RFC1510, September 1993,
			<http://www.rfc-editor.org/info/rfc1510>.
	Author's Address		Author's Address
	Tom Yu		Tom Yu
	MIT Kerberos Consortium		MIT Kerberos Consortium
	77 Massachusetts Ave		77 Massachusetts Ave
	Cambridge, Massachusetts		Cambridge, Massachusetts
	USA		USA
	Email: tlyu@mit.edu		Email: tlyu@mit.edu
End of changes. 21 change blocks.
	16 lines changed or deleted		29 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/