Subject: [Ietf-krb-wg] I-D Action: draft-ietf-kitten-kerberos-iana-registries-00.txt

From: Tom Yu <[email-masked]>
Date: Mon, 15 Oct 2012 20:22:17 -0400

From: [email-masked]
To: [email-masked]
Subject: I-D Action: draft-ietf-kitten-kerberos-iana-registries-00.txt
Message-ID: <[email-masked]>
Date: Mon, 15 Oct 2012 16:52:22 -0700
Cc: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF.

	Title           : Move Kerberos protocol parameter registries to IANA
	Author(s)       : Tom Yu
	Filename        : draft-ietf-kitten-kerberos-iana-registries-00.txt
	Pages           : 6
	Date            : 2012-10-15

Abstract:
   The Keberos 5 network authentication protocol has several numeric
   protocol parameters.  Most of these parameters are not currently
   under IANA maintenance.  This document requests that IANA take over
   the maintenance of the remainder of these Kerberos parameters.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-kitten-kerberos-iana-registries

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-kitten-kerberos-iana-registries-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: t.p. <[email-masked]>
Date: Tue, 23 Oct 2012 14:51:17 +0100

The IANA Considerations in this I-D looks rather thin for a document
that is setting up an IANA registry, while for the rest of the document,
I find myself overwhelmed by
detail, lacking an overview, a framework into which to put things.

A registry usually has
- Name, unique within the IANA namespace
- Administratrive restrictions
- Technical restrictions
- Initial contents
and at least the first, I would expect to see under IANA Considerations,
with that same name appearing in the rest of the document.  The rest of
information may then be in that section or else be pointed to from that
section.

Here I see
"This document requests that IANA create several registries for
   Kebreros protocol parameters.  "

Reading the rest of the document, with each registry being identified by
a prefix (in practice, one, two or more prefixes) it would seem that
some nine or so registries are being placed under IANA, with the initial
contents coming, in several cases, from section 7 of RFC4120.

Um, sounds like a bottom-up design, a possible recipe for confusion.

Tom Petch

----- Original Message -----
From: "Tom Yu" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, October 16, 2012 1:22 AM

>  This draft is a work item of the Common Authentication Technology
Next Generation Working Group of the IETF.
> The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-kitten-kerberos-iana-registr
ies

---

From: t.p. <[email-masked]>
Date: Wed, 24 Oct 2012 10:39:46 +0100

p.s.  Since this is in the Charter for krb-wg, I assume that the right
place for discussion, unless and until the WGs are merger, is the krb-wg
list and not the kitten one.  I am subscribed to the former but not, at
present, to the latter.

Tom Petch

---

From: t.p. <[email-masked]>
Date: Fri, 26 Oct 2012 17:24:07 +0100

I did a concordance on this I-D, the IANA Kerberos entries
and RFC4120 which yields, crudely,
==========================================

** RFC4120                              I-D
7.5. Protocol Constants and Associated Values 106
7.5.1. Key Usage Numbers            106 s4.4
7.5.2. PreAuthentication Data Types 108 s4.6 already in IANA
7.5.3. Address Types                109 s4.1
7.5.4. Authorization Data Types     109 s4.2
7.5.5. Transited Encoding Types     109 {?? ONLY ONE VALUE}
7.5.6. Protocol Version Number      109 {not worth registering}
7.5.7. Kerberos Message Types       110 {?? why not}
7.5.8. Name Types                   110 s4.5
7.5.9. Error Codes                  110 s4.3
5.5.1  AP-REQ                           s5.1
5.4.1  KDC-REQ                          s5.2
5.3    Ticket Flags                     s5.3

** IANA website 23Oct2012

Checksum Type Numbers RFC 3961 Standards Action or Expert Review (Ken
Raeburn)

Encryption Type Numbers  RFC 3961 Standards Action or Expert Review (Ken
Raeburn)

FAST Armor Types  RFC 6113 Standards Action

FAST Options  RFC 6113 Standards Action

Kerberos Message Transport Types  draft-sakane-dhc-dhcpv6-kdc-option-18
IETF Review

Kerberos TCP Extensions  RFC 5021 IESG Approval or Standards Action

Pre-authentication and Typed Data  RFC 6113 Expert Review (expert may
find that IETF Review is required) (Experts: Sam Hartman - primary,
Larry Zhu - secondary)

Well-Known Kerberos Principal Names draft-ietf-krb-wg-naming-07
Specification Required
Well-Known Kerberos Realm Names draft-ietf-krb-wg-naming-07
Specification
Required
============================================

from which I think that this I-D should contain

7.5.1. Key Usage Numbers            106 s4.4
7.5.3. Address Types                109 s4.1
7.5.4. Authorization Data Types     109 s4.2
7.5.8. Name Types                   110 s4.5
7.5.9. Error Codes                  110 s4.3
5.5.1  AP-REQ                           s5.1
5.4.1  KDC-REQ                          s5.2
5.3    Ticket Flags                     s5.3

(not necessarily in that order)
but should not contain
7.5.2. PreAuthentication Data Types 108 s4.6
as it is already in IANA - but a line saying that would seem
appropriate.
As for

Transited Encoding Types
Protocol Version Number

they do not seem worthy of a registry but I am puzzled by the omission
from the I-D of
 Kerberos Message Types
which looks like an incipient registry to me.

Tom Petch

----- Original Message -----
From: "t.p." <[email-masked]>
To: <[email-masked]>; "Tom Yu" <[email-masked]>
Sent: Wednesday, October 24, 2012 10:39 AM

> > Reading the rest of the document, with each registry being
identified
> by
> > > A New Internet-Draft is available.
> > > Filename        :
draft-ietf-kitten-kerberos-iana-registries-00.txt
htmlized version available at:

---

From: Tom Yu <[email-masked]>
Date: Fri, 26 Oct 2012 14:26:34 -0400

"t.p." <[email-masked]> writes:

>>From the I-D of

Transited Encoding types should probably have a registry for the sake
of completeness, even though there are unlikely to ever be any more,
and it's best to leave them for standards action.

The protocol version number is effectively never going to change, for
various reasons.

Message types are probably not suitable for registration.  The sort of
change that would result in a new message type number would be a
significant change to the protocol, well beyond what reasonable people
might agree is a new protocol parameter value.

Message types are identical to the ASN.1 application tag numbers of
protocol messages that contain them.  In any given type of protocol
message, the msg-type value will never change.  New message type
numbers will only come into existence with new protocol messages, and
thus be subject to standards action.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: t.p. <[email-masked]>
Date: Sat, 27 Oct 2012 12:07:47 +0100

----- Original Message -----
From: "Tom Yu" <[email-masked]>
To: "t.p." <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, October 26, 2012 7:26 PM
> thus be subject to standards action.

Um; that logic seems to say that anything that is subject to Standards
Action need not be in the IANA registry, which seems to me to be quite
wrong.  It would, however, enable us to eliminate much of the current
web site.

The IANA registry is a major source of information, a centralised
database of anything, in the shape of a name or a number, that you need
to know in order to understand or deal with the Internet.   Thus SNMP
puts Security Models and Message Models there, a new one of which would
take a new Working Group and years of work to produce.  I am sure that
there are many more such cases in our core protocols.  Having a central
source, with references, makes the information usable to everyone.

So, I think that Kerberos Message Types would make a most useful
registry.

Tom Petch

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 28 Oct 2012 00:47:01 -0400

> So, I think that Kerberos Message Types would make a most useful

No, Tom's point here is that the message type numbers are in fact in
exactly the same situation as the protocol version -- in any place where
such a number appears, there is only one value that can possibly appear
there; any other value is a protocol error, not an opportunity for
extension.  In particular, message types are not used to distinguish
between messages -- they cannot be, since they are contained within each
PDU and such distinction must be done before a PDU can be parsed.

IANA registries are not intended as "a centralised database of anything
[...] you need to know in order to understand or deal with the
Internet".  They are intended to serve as a mechanism for the management
of namespace, to insure that the same name (number) is not reused for
more than one purpose.  Where there is nothing to manage, there is no
need for a registry.

-- Jeff