Re: [kitten] Review of draft-ietf-kitten-krb-service-discovery-00

[Greg Hudson <[e-mail]>]

On 03/30/2017 02:51 PM, Matt Rogers wrote:
>> * RFC 7553 is informational and this document is standards track, which
>>   is a down reference (see RFC 3967).  Also, RFC 7553 contains ambiguous
>>   guidance about URI records labels which some readers have interpreted
>>   as being incompatible with our use of labels.  I think at one point we
>>   received advice to reference the IANA registration of the URI record
>>   type instead of RFC; unfortunately I do not know the mechanics of that
>>   kind of reference.

> The IANA registration entry refers to RFC 7553:
> https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml
> Perhaps it should just be an informative reference instead.

There is also a "completed template" in the IANA assignment:

https://www.iana.org/assignments/dns-parameters/URI/uri-completed-template

I hadn't read this before.  It says (in section E):

  The URI RR has service information encoded in its ownername.  In
  order to encode the service for a specific owner name one uses
  service parameters.  Valid service parameters used are either
  Enumservice Registrations registered by IANA, or prefixes used
  for the SRV resource record.

which seems like a slightly more restrictive statement than the one in
RFC 7553.  We may need some guidance from the chairs or ADs on the
mechanics of moving forward here.  Simply making the reference
informative doesn't seem sufficient, as the URI RR type is fundamental
to this standard.

(To be clear, I think what we're doing ought to be fine, and that it's
generally pointless to include a transport label in a URI record owner
name like one would in a SRV owner name.  The question is one of
conformance with the pre-existing standard, not practicality.)

>> * Similarly, MS-KKDCP is in the normative references section, and is not
>>   a standards-track IETF document.  It is only used as the reference in
>>   the initial contents of the transport registry, so perhaps it can just
>>   be an informative reference.
>>
> I'll make this an informative reference.

The MS-KKDCP reference is obvious controlling when using the kkdcp
transport.  Since this is just an initial transport registration, it may
be okay to use an informative reference.

>> * "REALM indicates the translation of the Kerberos realm to a DNS
>>    domain" seems to invoke some kind of translation procedure without a
>>    reference.  RFC 4120 doesn't really define any such translation
>>    procedure; it just says in section 6.1 that a realm might be in
>>    domain style with some specifics on what that means, and in section
>>    7.2.3.2 that "The realm MUST be a domain-style realm name".
>>
>>    (Section 6 has this same wording again.)
> 
> How about "..client MUST query the following URI DNS record, where
> REALM is a domain-style realm name."

I'm okay with that.

>> * The wording here seems too general.  I think we want to specifically
>>   say that URI records should be preferred over SRV records.

> How about: "Clients that support service discovery through both URI
> and SRV records SHOULD perform the URI discovery first. If no URI
> record is found, the client MAY then attempt SRV discovery."

Sure.

There is an argument for a MUST here.  DNS administrators will commonly
want to set up both URI and SRV records for a realm, and the behavior of
trying URI first may be important (e.g. if the URI record includes a
kkdcp entry).

>> * The reference here is "TBD".  Is there a plan?  Is the reference
>>   supposed to be to this RFC once a number is assigned?
>>
> 
> It should be changed to the assigned number, yes. It was suggested
> that instead of TBD we use [This Document], which I think is the
> convention for this kind of reference.

That seems okay.  There might also need to be an RFC editor guidance
section pointing out the need for a substitution there.  For instance,
in https://tools.ietf.org/html/draft-ietf-krb-wg-crypto-07 see the
"Notes to RFC Editor" section at the end.

> "The security implication of using DNS URI records is identical to
> that of using DNS for any Kerberos service or host mapping; without
> secure DNS the results can be forged.  The same precautions regarding
> the use of insecure DNS with Kerberos outlined in RFC 4120 should be
> followed."

RFC 4120 primarily talks about DNS in the context of prohibiting the use
of insecure DNS to map between service names, which is irrelevant to
this standard.

Since RFC 4120 assumes a hostile network environment (and so does RFC
3244), it is usually uninteresting whether an attacker subverts
communication via a DNS attack or a network attack.  However, we should
note in security considerations that the added security benefits of
MS-KKDCP (such as confidentiality of client and server principal names)
are eroded when using insecure DNS to discover the server URL.