The Kerberos Network Authentication Service (V5)
draft-ietf-krb-wg-kerberos-clarifications-07

[Ballot comment]
Reviewed by Joel Halpern, Gen-ART

His review:

As far as I can tell, this draft is ready for publication as a
Propsoed Standard RFC

nit: 2026 rather than 3667, and no intellectual property disclosure
statement.
nit: The title claims this is a clarification, while the document is an overview and specification.  The abstract indicates that the reason for redoing the specification is to clarify the previous version, but it is a full specification, not a "clarification", and ought to be titled as such.
nit: In section 6.1 in describing the provision for the currently unused "other" types of realms, the construct "All prefixes expect those beginning with used."
appears.  While typographically a sentence, even in context I can not parse it at all.

[Ballot discuss]
I'm very impressed with this document -- it's an impressive effort to clarify a very large, very complex, ancient spec.

7.1    Why are link-local addresses banned?

[Ballot discuss]
I'm very impressed with this document -- it's an impressive effort to clarify a very large, very complex, ancient spec.

7.1    Why are link-local addresses banned?  For that matter, why
        are loopback addresses banned?  On many platforms, packets
        to the local host are routed to the loopback interface;
        for UDP-based services, this may result in them having a
        source address of the loopback address, which in turn could
        cause problems if the site (against advice) chooses to
        included addresses in tickets.

[Ballot comment]
None of the protocol constants are maintained by IANA? This seems like
a disaster waiting to happen. Recommendation: start effort to create
an IANA considerations for Kerberos RFC, outlining the various name
spaces, getting a definitive registry maintained by IANA, and
specifying what the policies are for future assignments. Note: WG
should have a look at RFC 2434 and also
draft-narten-iana-experimental-allocations-05.txt for background.

[Ballot discuss]
I'm very impressed with this document -- it's an impressive effort to clarify a very large, very complex, ancient spec.

meta-note:  should we permit end-notes in RFCs?

3.2.2  Authenticators MAY NOT be re-used
        and *SHOULD* be rejected if replayed to a server[9]

3.3.3  "Thss is theonly cases where..." ?

3.4.1  What's wrong with gaps in a sequence-numbered service?
        IPsec handles it just fine, using a sliding window.
       
3.4.2  Are out-of-order timestamps (but within the skew) permitted?
        The spec is silent on that.  (Also 3.5.2)

5.1.4  "gracefully handling" an unkown class tag isn't always
        compatible with sending an error message.  When is it
        or is it not "appropriate"?  When can unknown tags be ignored?

5.1.5  I wouldn't permit newlines in lengthy error strings;
        display them is a user interface issue, and local
        constraints dictate where to break lines.

5.5.1  I wonder if 32 bits is enough for a sequence number.
        ESP had to extend that.  But sequence number wrapping is
        not good with 64-bit block ciphers such as 3DES; should
        there be a requirement to rekey rather than wrapping around?

7.1    Why are link-local addresses banned?  For that matter, why
        are loopback addresses banned?  On many platforms, packets
        to the local host are routed to the loopback interface;
        for UDP-based services, this may result in them having a
        source address of the loopback address, which in turn could
        cause problems if the site (against advice) chooses to
        included addresses in tickets.


7.2.3.1 I don't think that internationalized domain names are
        case-sensitive.

9      Use 2434 language.

10      Warn about DES

13      Split references into normative/informative

[Ballot comment]
I don't like endnotes.
Given the prevalence of [5] in the ASN.1 notation, it's even extraordinarily hard to figure out where they are referred from.
The discussion of charset usage is sad to read, but seems sensible.....

[Ballot discuss]
In adding mandatory TCP transport (beyond 1510),
a length field preceding the messages is added,
with the high bit reserved as zero to allow
future expansion.  The rule below seems like
asking for trouble (easy TCP DoS).  Is that
reserved bit really needed?  Consider not
having it?


  If a KDC that does not understand how to
  interpret a set high bit of the
  length encoding receives a request with
  the high order bit of the
  length set, it MUST return a
  KRB-ERROR message with the error
  KRB_ERR_FIELD_TOOLONG and MUST close
  the TCP stream.

------

Ted's Discuss covers issues about SRV being 2052 instead of
2782, and others, but there's one more:
I think it would be fairly hard to create a fake KDC
for a domain, but the SRV discovery method should note
that DNS security is needed to prevent misdirection to a fake.

[Ballot discuss]
meta-note:  should we permit end-notes in RFCs?

3.2.2  Authenticators MAY NOT be re-used
        and *SHOULD* be rejected if replayed to a server[9]

3.3.3  "Thss is theonly cases where..." ?

3.4.1  What's wrong with gaps in a sequence-numbered service?
        IPsec handles it just fine, using a sliding window.
       
3.4.2  Are out-of-order timestamps (but within the skew) permitted?
        The spec is silent on that.  (Also 3.5.2)

5.1.4  "gracefully handling" an unkown class tag isn't always
        compatible with sending an error message.  When is it
        or is it not "appropriate"?  When can unknown tags be ignored?

5.1.5  I wouldn't permit newlines in lengthy error strings;
        display them is a user interface issue, and local
        constraints dictate where to break lines.

5.5.1  I wonder if 32 bits is enough for a sequence number.
        ESP had to extend that.  But sequence number wrapping is
        not good with 64-bit block ciphers such as 3DES; should
        there be a requirement to rekey rather than wrapping around?

7.1    Why are link-local addresses banned?  For that matter, why
        are loopback addresses banned?  On many platforms, packets
        to the local host are routed to the loopback interface;
        for UDP-based services, this may result in them having a
        source address of the loopback address, which in turn could
        cause problems if the site (against advice) chooses to
        included addresses in tickets.


7.2.3.1 I don't think that internationalized domain names are
        case-sensitive.

9      Use 2434 language.

10      Warn about DES

13      Split references into normative/informative

[Ballot comment]
Section 1.1


---> KDCs are SHOULD honor this flag.

The "are" looks spurious.

Section 1.2

The text uses "canonicalize" in a way that may cause confusion.  The text seems to mean:
"don't use the DNS to map one name to another as a way of determining who to talk to",
but "canonicalize" has a common reading of 'shift "NeXT.com" to "next.com" for matching'
that might get in the way here.

Informative reference to the documents for PKTAPP needed.

This is not a discuss, but this note in 3.2.3 concerns me:

  Implementation note: If a client generates multiple requests to the
  KDC with the same timestamp, including the microsecond field, all but
  the first of the requests received will be rejected as replays. This
  might happen, for example, if the resolution of the client's clock is
  too coarse.  Implementations SHOULD ensure that the timestamps are
  not reused, possibly by incrementing the microseconds field in the
  time stamp when the clock returns the same time for multiple
  requests.

I'm not sure that I understand why simply accepting the rejection as a
valid rejection of replays isn't the right answer here.  In situations where
a client is using a shared system clock, it seems possible that the repeated
timestamp might be due to externally-applied corrections to skew of
the system clock.  More generally, though, I'm not sure how the client
is to know the cause of the timestamp repeat, and without that knowledge,
suggesting this course of action seems a bit off.

Section 3.3.1

--->(This paragraph changed)
Text above probably not needed.


Section 4.

-->if not key usage values are specified then key usages 1024 and 1025
Should be "if no key usage values"?

The text here in Section 5:

  Note that elsewhere in this document, nomenclature for various
  message types is inconsistent, but seems to largely follow C language
  conventions, including use of underscore (_) characters and all-caps
  spelling of names intended to be numeric constants.

seems odd. I assume it means "draft-ietf-krb-wg-kerberos-clarifications...seems
to largely follow", but that distancing from the current draft made me wonder
if it meant 1510 or 1964 (referenced just above).  I'd suggest rewording it
to avoid the "seems"

In 7.4, the draft says "assignment of OIDs beneath the id-krb5 arc must be obtained by
contacting krb5-oid-registrar@mit.edu."  Do we want that fixed in
the draft, or have the contact listed somehow at IANA, so it could change
if mit.edu needed to put it in a sub-domain or otherwise move it?

[Ballot discuss]
Section 6.1 says:


  Names that fall into the other category MUST begin with a prefix that
  contains no equal (=) or period (.) and the prefix MUST be followed
  by a colon (:) and the rest of the name. All prefixes must be
  assigned before they may be used. Presently none are assigned.

The IANA considerations does not note Section 6.1, and I saw no kerberos
prefix registry at IANA.  How are these assigned?

In discussions of SRV, the document cites 2052 instead of 2782.  2782
gives the format of SRV as:

_Service._Proto.Name TTL Class SRV Priority Weight Port Target

instead of

Service.Proto.Realm TTL Class SRV Priority Weight Port Target

as the draft lists it.  The substitution of Realm for Name seems
like it might result in an illegal query for the SRV record if the Realm
type is not "domain" (as per section 6.1).  Making that restriction explicit seems
like a good idea (with x500 the disconnect may be obvious but with "other"
in the mix, this restriction may not be obvious for all possible prefixes)

[Ballot discuss]
Section 6.1 says:


  Names that fall into the other category MUST begin with a prefix that
  contains no equal (=) or period (.) and the prefix MUST be followed
  by a colon (:) and the rest of the name. All prefixes must be
  assigned before they may be used. Presently none are assigned.

The IANA considerations does not note Section 6.1, and I saw no kerberos
prefix registry at IANA.  How are these assigned?

[Ballot comment]
Section 1.1


---> KDCs are SHOULD honor this flag.

The "are" looks spurious.

Section 1.2

The text uses "canonicalize" in a way that may cause confusion.  The text seems to mean:
"don't use the DNS to map one name to another as a way of determining who to talk to",
but "canonicalize" has a common reading of 'shift "NeXT.com" to "next.com" for matching'
that might get in the way here.

Informative reference to the documents for PKTAPP needed.

This is not a discuss, but this note in 3.2.3 concerns me:

  Implementation note: If a client generates multiple requests to the
  KDC with the same timestamp, including the microsecond field, all but
  the first of the requests received will be rejected as replays. This
  might happen, for example, if the resolution of the client's clock is
  too coarse.  Implementations SHOULD ensure that the timestamps are
  not reused, possibly by incrementing the microseconds field in the
  time stamp when the clock returns the same time for multiple
  requests.

I'm not sure that I understand why simply accepting the rejection as a
valid rejection of replays isn't the right answer here.  In situations where
a client is using a shared system clock, it seems possible that the repeated
timestamp might be due to externally-applied corrections to skew of
the system clock.  More generally, though, I'm not sure how the client
is to know the cause of the timestamp repeat, and without that knowledge,
suggesting this course of action seems a bit off.

Section 3.3.1

--->(This paragraph changed)
Text above probably not needed.


Section 4.

-->if not key usage values are specified then key usages 1024 and 1025
Should be "if no key usage values"?

The text here in Section 5:

  Note that elsewhere in this document, nomenclature for various
  message types is inconsistent, but seems to largely follow C language
  conventions, including use of underscore (_) characters and all-caps
  spelling of names intended to be numeric constants.

seems odd. I assume it means "draft-ietf-krb-wg-kerberos-clarifications...seems
to largely follow", but that distancing from the current draft made me wonder
if it meant 1510 or 1964 (referenced just above).  I'd suggest rewording it
to avoid the "seems"

[Ballot comment]
Section 1.1


---> KDCs are SHOULD honor this flag.

The "are" looks spurious.

Section 1.2

The text uses "canonicalize" in a way that may cause confusion.  The text seems to mean:
"don't use the DNS to map one name to another as a way of determining who to talk to",
but "canonicalize" has a common reading of 'shift "NeXT.com" to "next.com" for matching'
that might get in the way here.

Informative reference to the documents for PKTAPP needed.

This is not a discuss, but this note in 3.2.3 concerns me:

  Implementation note: If a client generates multiple requests to the
  KDC with the same timestamp, including the microsecond field, all but
  the first of the requests received will be rejected as replays. This
  might happen, for example, if the resolution of the client's clock is
  too coarse.  Implementations SHOULD ensure that the timestamps are
  not reused, possibly by incrementing the microseconds field in the
  time stamp when the clock returns the same time for multiple
  requests.

I'm not sure that I understand why simply accepting the rejection as a
valid rejection of replays isn't the right answer here.  In situations where
a client is using a shared system clock, it seems possible that the repeated
timestamp might be due to externally-applied corrections to skew of
the system clock.  More generally, though, I'm not sure how the client
is to know the cause of the timestamp repeat, and without that knowledge,
suggesting this course of action seems a bit off.

[Ballot comment]
No objection, but a bunch of nits:

Really small stuff:

  References not split into normative and informative groups
  MUST/SHOULD/etc. used but not defined
  No copyright boilerplate
  No IPR boilerplate

The abstract talks about how this document "updates" RFC 1510. (The
I-D also implies that this is an updates. But it quickly becomes clear
that this document obsoletes RFC 1510, it doesn't just add to it. Suggest
that this be clarified.

Section 7.2.3.1 seems a bit dated in light of where IDN ended up. In
particular, the notion that the DNS is going to shift to using
case-sensitive labels seems a bit unlikely given that IDN does
stringprep-based case normalization.

More generally, no mention is given of IDN. Addressing IDN issues here
is almost certainly inappropriate, but perhaps a note saying they will
be looked at in a future revision is in order.

-- end of nits --

The trick of switching from namedbits to a BITSTRING (32..MAX) in order
to work around implementations not doing zero bit truncation is a hack
only ASN.1 could possibly deserve.

I also have to say that I find the ISO-2022 G0 restriction conflicting
with DER's G0-only policy to be quite amusing.