Subject: Re: [Ietf-krb-wg] I-D Action:draft-sakane-dhc-dhcpv6-kdc-option-09.txt

From: Shoichi Sakane <[email-masked]>
Date: Wed, 20 Apr 2011 14:04:52 +0900

Jeff,

Thank you for your comment.

> On Tue, 2010-10-26 at 16:45 -0400, Jeffrey Hutzelman wrote:
> > > Section 3.2:
> > > This section defines a "Kerberos Realm Name" option, but incorrectly
> > > uses the option code OPTION_KRB_KDC_OPTION, and doesn't describe the
> > > semantics of the provided realm name.  It's clearly not the client's
> > > default realm, which is what OPTION_KRB_DEFAULT_REALM_NAME is for.
> > > In the previous version of the document, the implication was that one
> > > could mention a realm and then a number of KDC's for that realm, but
> > > top-level DHCP options must not have order dependencies.  So, we need
> > > to either drop the concept of providing information about KDC's for
> > > multiple realms, or combine a realm name and list of KDC's into one
> > > DHCPv6 option.
> This is actually a multi-part issue, none of which was addressed in -10:
>
> - The diagram for the "Kerberos Realm Name" option shows use of the
>   option code OPTION_KRB_KDC_OPTION, where the correct code is
>   OPTION_KRB_REALM_NAME

I found another typo as well.  all are fixed.
To follow other option's code, "OPTION_KRB_KDC_OPTION" is changed to
"OPTION_KRB_KDC".

> - It's not at all clear what this option _means_, which makes me very
>   dubious that interoperable implementation is possible.  As I mention
>   above, I can see a use that worked before, when we had suboptions
>   whose order was meaningful, but that can't work now, because we no
>   longer have suboptions and the order of DHCP options cannot matter.

> The second part is more complicated.  If the realm name option is
> intended to identify the realm associated with a set of KDCs, then we
> need to say that.  If it is intended to be possible to list KDCs for
> more than one realm, we need to figure out some ways to indicate which
> KDCs belong to which realm, and that will require WG discussion and
> consensus (or, of course, we could drop that capability, which would
> also require WG consensus).
>
> If the realm name option is intended for something else entirely, I
> don't know what it is, which means that someone reading the document who
> has no familiarity with Kerberos or with the problem you're trying to
> solve certainly won't know either.  That means we need to be more clear
> about what this option is for.

The kerberos KDC option now includes both a realm name
and an IPv6 address so that DHCPv6 server can provide the
information regardless of the order.

The realm name option is intended that a DHCPv6 server determines
a set of the configuration parameters of a KDC in a Kerberos realm
specified by the realm-name field.

when a dhcpv6 client only knows its realm name but does not know
the kdc address of the realm,  the client can ask dhcpv6 server
kdc addresses by sending the realm option.

I improved the text in section 3.2 and 3.3 in case.

   3.2.  Kerberos Realm Name Option

      This option provides a realm name of the Kerberos system.  It is
      intended for a DHCPv6 client use, which indicates what kind of KDC
      address that the client needs.  A DHCPv6 server determines a set of
      the configuration parameters of a KDC in a Kerberos realm specified
      by the realm-name field in this option.

   3.3.  Kerberos Default Realm Name Option

      This option provides a default realm name of the Kerberos system.
      Contrary to the Kerberos Realm Name Option, it is intended for a
      DHCPv6 server use, which notifies the default realm name to both
      clients and servers in the Kerberos system.

Should I submit it right now ?

Regards,

Shoichi

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg