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

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
In general:

* 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.

* 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.

Abstract:

* I would rephrase or omit the fourth goal ("define a discovery
  procedure for Kerberos password services").  There is an
  interoperable, well-documented[1] de facto standard for discovering
  kpasswd services; it just isn't specified in an RFC.  It's debatable
  whether this is a serious enough deficit to mention in the abstract as
  a problem that we're solving; if it is, I would say "formally specify"
  rather than "define" to make it clear that the problem being remedied
  is the lack of a formal specification.

Section 4.2 (Flags):

* seperating -> separating

* eg. -> e.g. (two places; I think this is the accepted RFC style based
  on a very brief survey)

* Section 4.2.1 (Master Flag) is too focused on password changes, I
  think.  I suggest:

  The client SHOULD consider this server as one that might possess more
  up-to-date long-term key material, and use it as a fallback for errors
  that might result from out-of-date keys.

  (Although MIT krb5 currently only uses the master KDC for AS requests,
  Roland has pointed out that we really ought to use it for TGS requests
  as well due to krbtgt key rollovers.)

Section 4.4 (Residual):

* I suggest "where such are defined" -> "as defined"

Section 5 (Kerberos V5 KDC Service Discovery):

* "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.)

Section 7 (Kerberos Admin Service Discovery):

* There is no standard admin protocol, even a de facto one (well,
  Heimdal has some interoperability with MIT krb5).  It doesn't make a
  lot of sense to specify a standard discovery protocol when there is no
  standard for what is being discovered.  I think we want to leave this
  as an implementation-specific aside.

  This change would have an impact on section 9.2.1 (removing the
  default admin service port) and 9.2.2.

Section 8 (Relationship to Existing Mechanism):

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

Section 9.1.2 (Initial Registry Contents, for flags registry):

* The reference here is "TBD".  Is there a plan?  Is the reference
  supposed to be to this RFC once a number is assigned?

[1] https://technet.microsoft.com/en-us/library/cc961719.aspx
    http://web.mit.edu/kerberos/krb5-latest/doc/admin/realm_config.html#hostnames-for-kdcs
    http://www.h5l.org/manual/HEAD/info/heimdal/Setting-up-DNS.html#Setting-up-DNS

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Henry B (Hank) Hotz, CISSP-2

> On Mar 21, 2017, at 8:54 AM, Greg Hudson <[hidden email]> wrote:
>
> Section 7 (Kerberos Admin Service Discovery):
>
> * There is no standard admin protocol, even a de facto one (well,
>  Heimdal has some interoperability with MIT krb5).  It doesn't make a
>  lot of sense to specify a standard discovery protocol when there is no
>  standard for what is being discovered.  I think we want to leave this
>  as an implementation-specific aside.

Mildly disagree.

Mainly because there is RFC 6860. As a weaker argument, I still think it makes sense to specify how to find the admin service, even if the details of that service are “implementation specific”.

Of course, having done that much, one wonders if we couldn’t specify an interoperable subset of an admin protocol which implements “enough of” 6860. . .  Experience with 6860 would suggest there isn’t sufficient interest to support that effort though.

>  This change would have an impact on section 9.2.1 (removing the
>  default admin service port) and 9.2.2.

Personal email.  [hidden email]



_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Altman-2
On 3/21/2017 4:16 PM, Henry B (Hank) Hotz, CISSP wrote:

>
>> On Mar 21, 2017, at 8:54 AM, Greg Hudson <[hidden email]> wrote:
>>
>> Section 7 (Kerberos Admin Service Discovery):
>>
>> * There is no standard admin protocol, even a de facto one (well,
>>  Heimdal has some interoperability with MIT krb5).  It doesn't make a
>>  lot of sense to specify a standard discovery protocol when there is no
>>  standard for what is being discovered.  I think we want to leave this
>>  as an implementation-specific aside.
>
> Mildly disagree.
>
> Mainly because there is RFC 6860.
Hi Hank,

I'm confused, what does RFC 6860 "Hiding Transit-Only Networks in OSPF"
have to do with this draft?  Is there a different RFC you are thinking
about?

Jeffrey Altman



_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
In reply to this post by Henry B (Hank) Hotz, CISSP-2
On 03/21/2017 04:16 PM, Henry B (Hank) Hotz, CISSP wrote:
> Mildly disagree.
>
> Mainly because there is RFC 6860.

I think Hank meant RFC 6880 (KDC Information Model), to answer Jeffrey
Altman's question.

I will argue that in complexity, a discovery mechanism is small, an
information model is medium, and an administrative protocol is large.  I
argued that the URI discovery draft creates:

  [discovery] -> <empty void of no admin protocol>

Adding RFC 6860 into the mix just changes the picture to:

  [disc] -> <empty void of no admin protocol> -> [info model]

They don't connect up, and the missing piece is much larger than the
pieces on either side.  As there is no indication that a complete
picture is forthcoming, I believe that any DNS discovery protocol for
the implementation-specific admin service should also be considered
implementation-specific.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Altman-2
On 3/23/2017 1:06 PM, Greg Hudson wrote:
> I believe that any DNS discovery protocol for
> the implementation-specific admin service should also be considered
> implementation-specific.

I concur.

Jeffrey Altman



_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Henry B (Hank) Hotz, CISSP-2
In reply to this post by Greg Hudson

> On Mar 23, 2017, at 10:06 AM, Greg Hudson <[hidden email]> wrote:
>
> On 03/21/2017 04:16 PM, Henry B (Hank) Hotz, CISSP wrote:
>> Mildly disagree.
>>
>> Mainly because there is RFC 6860.
>
> I think Hank meant RFC 6880 (KDC Information Model), to answer Jeffrey
> Altman's question.

Yes. (Copy-by-hand considered dangerous.)

> I will argue that in complexity, a discovery mechanism is small, an
> information model is medium, and an administrative protocol is large.  I
> argued that the URI discovery draft creates:
>
>  [discovery] -> <empty void of no admin protocol>
>
> Adding RFC 6860 into the mix just changes the picture to:
>
>  [disc] -> <empty void of no admin protocol> -> [info model]
>
> They don't connect up, and the missing piece is much larger than the
> pieces on either side.  As there is no indication that a complete
> picture is forthcoming, I believe that any DNS discovery protocol for
> the implementation-specific admin service should also be considered
> implementation-specific.

My opinion hasn’t changed. I think the service discovery protocols for everything ought to be similar so they ought to be specified together.

I will note that failing to include something I wanted is not a reason to oppose the entire draft. I can live with being in the rough for this point.


Personal email.  [hidden email]



_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Matt Rogers
In reply to this post by Greg Hudson
On Tue, Mar 21, 2017 at 11:54 AM, Greg Hudson <[hidden email]> wrote:

> In general:
>
> * 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.

> * 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.

> Abstract:
>
> * I would rephrase or omit the fourth goal ("define a discovery
>   procedure for Kerberos password services").  There is an
>   interoperable, well-documented[1] de facto standard for discovering
>   kpasswd services; it just isn't specified in an RFC.  It's debatable
>   whether this is a serious enough deficit to mention in the abstract as
>   a problem that we're solving; if it is, I would say "formally specify"
>   rather than "define" to make it clear that the problem being remedied
>   is the lack of a formal specification.

I think "formally specify" would be better.

>
> * Section 4.2.1 (Master Flag) is too focused on password changes, I
>   think.  I suggest:
>
>   The client SHOULD consider this server as one that might possess more
>   up-to-date long-term key material, and use it as a fallback for errors
>   that might result from out-of-date keys.
>
Works for me.

> Section 4.4 (Residual):
>
> * I suggest "where such are defined" -> "as defined"
>

This will be removed with the Residual section (based on past comments
to redefine the fields as
"krb5srv:[flags]:transport-type:transport-info")

> Section 5 (Kerberos V5 KDC Service Discovery):
>
> * "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."

>
> Section 7 (Kerberos Admin Service Discovery):
>
> * There is no standard admin protocol, even a de facto one (well,
>   Heimdal has some interoperability with MIT krb5).  It doesn't make a
>   lot of sense to specify a standard discovery protocol when there is no
>   standard for what is being discovered.  I think we want to leave this
>   as an implementation-specific aside.
>
>   This change would have an impact on section 9.2.1 (removing the
>   default admin service port) and 9.2.2.
>
I'm OK with removing this part.

> Section 8 (Relationship to Existing Mechanism):
>
> * 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."

> Section 9.1.2 (Initial Registry Contents, for flags registry):
>
> * 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.

I'd also like to get some thoughts on this text for a Security
Considerations section:
"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."

Thanks,
Matt

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
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.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Matt Rogers
On Mon, Apr 3, 2017 at 12:32 PM, Greg Hudson <[hidden email]> wrote:

>
>   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.)
>

I'll leave this as normative at the moment, but perhaps it warrants
some text to explain the difference between our use of the owner name
and the RFC 7553 guidelines.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Kaduk-2
In reply to this post by Greg Hudson
On Mon, Apr 03, 2017 at 12:32:55PM -0400, Greg Hudson wrote:

> 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.

It's not entirely clear just how binding this is on consumers,
though I do think IANA consults this sort of thing sometimes.

> 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

Given how similar it is to the text in the RFC, I think we are
forced to conclude that the RFC takes precedence, possibly due to
last-minute changes.  (That is, that someone got sloppy at some
point.  But the RFC text is what has IETF consensus, and is thus
preferred.)  The relevant text was added in draft-faltstrom-uri-11,
FWIW.

We can call this issue out in the shepherd writeup for IESG
attention, too.  Making a final call is "above our pay grade" :)

> 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.)

It is correct to leave the reference as normative; the downref can
be called out during IETF last call (though, IIRC, some recent-ish
changes in policy do not mandate it quite as strongly as it used to
be).

> >> * 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.

I believe an informative reference is fine for this document, as
that spec is not needed in order to use the discovery protocol
itself.  (It's needed to use the results of discovery, but that's
out of scope.)

> >> * 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).

Note that the MUST only applies for implementations that claim to
comply with <RFC-to-be>, so it is not as strong a requirement as it
might seem at first.

> >> * 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.

Yes, "[this document]" is an accepted form.  I don't expect a
specific RFC Editor note is needed for this sort of usage.

-Ben

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten