Re: [Gen-art] Gen-art review of draft-sakane-dhc-dhcpv6-kdc-option-14.txt

[Stephen Farrell <[e-mail]>]

Hi,

On 05/28/2012 10:01 PM, ssakane wrote:
> All,
> 
> I have corresponded all you suggested, and made a new version of the draft.
> But, I haven't submitted it yet.
> 
> Corresponding to Alexey's review, I have merged both client operation
> and server operation into a single section: client and server operation
> in order for readers to understand the operations easily.
> And, I have improved the description of how a client gets information
> and what kind of information a server has to reply.
> 
> However, I am worry that this improvement will probably take this draft
> to the WG review phase again.
> I would like to ask from you whether my improvement was good way or not.

I'd say post the new revision and send a mail to the WG
list summarising the changes. There's no need to note
changes that are just to the layout of the text but if
there are changes to the protocol (e.g. addition of a
new MUST or something) then that's what the WG should
see. And if nobody yells, then we can go ahead.


> 
> And, I also need an input from you about 4.1. KDC discovery for a client
> because this behavior should be left to local matter.  I am thinking to
> just remove this diagram and its description.  See my response corresponding
> to Alexey's comment below.

Removing it seems fine to me, but maybe you want to
be more precise about what the administrator of the
realm MUST do here - just saying "define the method
for the client" isn't really clear, maybe say that
the administrator for the realm MUST pick one as
the preferred method for clients to use. (If that's
what you want to say.)

Jeff - if any of that is not what you prefer, please
say so, but posting the revision and moving this along
seems right to me.

Cheers,
S.

> 
> Anyway, for your help, I put the output of rfcdiff in
> 
> http://www.tanu.org/~sakane/limited/draft-sakane-dhc-dhcpv6-kdc-option-15-fr
> om-4.diff.html
> 
> Shoichi
> 
> 
> On 5/12/12 11:03 AM, "ssakane" <[e-mail]> wrote:
> 
>> Alexey,
>>
>> Thank you for your review and comments.
>>
>> Firstly, I really apologize that my response has been delayed.
>> I had some other deadlines last months.
>>
>> We totally agreed that the section 4 and 5 should be improved
>> to explain strictly the operations of both client and server.
>> Please wait for submitting new version in few weeks.
>>
>> Other responses are in-line.
>>
>>> I am the assigned Gen-ART reviewer for this draft. For background on
>>> Gen-ART, please see the FAQ at
>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>>
>>> Please resolve these comments along with any other Last Call comments
>>> you may receive.
>>>
>>> Document: draft-sakane-dhc-dhcpv6-kdc-option-14.txt
>>> Reviewer: Alexey Melnikov
>>> Review Date: 23 March 2012
>>> IETF LC End Date: 23 March 2012
>>> IESG Telechat date: (if known)  -
>>>
>>> Summary: I think this document needs another revision before being ready
>>> for IESG review, although I don't think that changes are difficult.
>>>
>>>
>>> 1.  Introduction
>>>
>>>     To provide a set of IP addresses of the KDC, the Kerberos V5
>>>     specification [RFC4120] defines KDC discovery by utilizing DNS SRV
>>>     records [RFC2782].  However, systems that do not employ the DNS, but
>>>     do use DHCP, do exist, for example industrial systems.  Some
>>>     industrial systems don't use DNS because they have already had their
>>>     own name spaces and their own name resolution systems, including pre-
>>>     configured mapping tables for devices, rather than using FQDNs and
>>>     DNS.  And these systems would prefer not to employ DNS only for name
>>>     resolution because adding a new server may bring a decrease in the
>>>     reliability of the system, and increase the management cost of the
>>>     system.
>>>
>>> Minor: I am a bit doubtful about this claim, but maybe this is just me.
>>> Many systems already depend on DNS. However, I think you might be
>>> missing out on showing another reason of why your extension might be
>>> useful: it might eliminate some DNS lookups and thus can speed-up
>>> acquisition of Kerberos credentials.
>>
>> You are correct on traditional IP-based systems such as networks of
>> university, business office, and a backbone of a building.
>> There are two reasons why we proposed these options.  Firstly, these
>> options are useful for bootstrapping of the clients of the kerberos
>> system.  This is written in the 5th paragraph of section 1.
>>
>> Secondly, there are domains not designed to use thorough IP functions.
>> Those systems have own name space and own name resolution mechanism,
>> but not DNS.  The systems are typically operated in the industry,
>> or building control systems.  Some of those systems were not integrated
>> communication security, and require it as a new function.  We are thinking
>> to integrate the kerberos system into those systems as long as not
>> breaking their original specification.  There is a more information
>> in the appendix A.
>>
>>> 3.3.  Kerberos Default Realm Name Option
>>>
>>>     This option provides a default realm name of the Kerberos system.
>>>     Unlike the Kerberos Realm Name Option, it is intended for a DHCPv6
>>>     server to use, and specifies the default realm name to both clients
>>>     and Kerberos application servers in the Kerberos system.
>>>
>>> Major: Can you give me an example of when this option might be different
>>> from the Kerberos Realm Name Option (section 3.2)?
>>
>> When a client does not know the realm name that the client should belong to,
>> the Default Realm Name Option is useful to tell the name to the client.
>> The DHCP sever provides it when the client didn't specify any option.
>> The server may select a specific realm name for the client by the principal
>> name in the Principal Name option which is given by the client.
>> This option was come up with by the discussion in the WG.
>> We described it in the 1st paragraph of section 3.3:
>>
>>    This option provides a default realm name of the Kerberos system.
>>    Unlike the Kerberos Realm Name Option, it is intended for a DHCPv6
>>    server to use, and specifies the default realm name to both clients
>>    and Kerberos application servers in the Kerberos system.
>>
>> In case when a client needs to know the Kerberos information in the specific
>> realm, the client use the Kerberos Realm Name Option to tell the realm name
>> to the DHCP server.
>>
>> We are going to add more detail in section 4 and 5.
>>
>>> 3.4.  Kerberos KDC Option
>>>
>>>     This option provides a set of configuration information about a KDC.
>>>
>>>     The format of the Kerberos KDC Option is:
>>>
>>>        0                   1                   2                   3
>>>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>        |         OPTION_KRB_KDC        |          option-len           |
>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>        |           Priority            |            Weight             |
>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>        | Transport Type|          Port Number          |               |
>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
>>>        |                                                               |
>>>        |                                                               |
>>>        |                       KDC IPv6 address        +---------------+
>>>        |                                               |               |
>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               :
>>>        :                                                               :
>>>        :                          realm-name                           :
>>>        :                       (variable length)                       :
>>>        :                                                               :
>>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>
>>> Major: realm-name is not described later in this section. I think it
>>> should be removed considering that you have 2 other options for Kerberos
>>> realms already.
>>
>> The description about realm-name itself is added in section 3.4.
>> Realm Option variants are all needed.  We are going to write them
>> about the operation of each server and client into section 4 and 5
>> respectively.
>>
>>> 4.  Client Operation
>>>
>>>     When the client requires configuration parameters for a Kerberos
>>>     system while bootstrapping, the client SHOULD put the client
>>>     principal name itself into the Kerberos Principal Name Option.
>>>
>>> Minor: So this option is only ever sent from a DHCP client to a DHCP
>>> server? Section 3.1 is not clear on that.
>>
>> Yes, it is.  
>>
>>>     When the client requires specific information for a certain realm,
>>>     the client SHOULD specify the realm name in the Kerberos Realm Name
>>>     Option.
>>>
>>> Minor: This might be answering one of my questions above, but I think
>>> you should make this clear in Section 3.2.
>>
>> A DHCP client sends this option to get a set of kerberos parameters.
>> We agree with you.  We will add more detail in both section 4 and 5.
>>
>>>     When the client requires specific information related to a
>>>     certain Kerberos application server of the Kerberos system, the
>>>     client SHOULD put the principal name of the server into the Kerberos
>>>     Principal Name Option.
>>>
>>> Major: Is such dual-purpose use a good idea?
>>
>> Yes, there is no reason to separate this option.
>> From the viewpoint of the DHCP server, the server just provides a certain
>> information related to the principal name a client sent.
>> From the viewpoint of a client, the client just put a principal name
>> of which the client want to know the information related to a Kerberos
>> application server or a Kerberos application client (i.e. the client itself).
>>
>>> 4.1.  KDC discovery for a client
>>>
>>>     1) Initially, the client asks both DNS and Kerberos information to
>>>        the DHCP server.
>>>
>>> Nit: s/to/from
>>>     6) If, as the result of (1), if the client gets both DNS and Kerberos
>>>        information from the DHCP server, then the client asks Kerberos
>>>        information to the DNS server.
>>>
>>> Nit: s/to/from
>>
>> Thanks for the corrections.
>>
>>> Minor: But this (or the diagram) looks confusing to me: if the client
>>> already got both Kerberos and other information from DHCP, why should it
>>> query DNS at all? I think either your diagram is confusing, or the
>>> description below, or both.
>>
>> In the early stage of writing this document, we think the DNS method should
>> be preferred because the method was standardized already.  We wanted to avoid
>> conflict as much as possible.
>>
>> However, we have already described that it must be defined by the
>> administrator in the draft.  And, from your comments, we are shifting to
>> different mind that such behavior should be left to the administrator of
>> the system.  So, we are thinking that the diagram and its description is
>> not needed anymore.
>>
>> If you think that it is better to remove this description from
>> "When there are no criteria in the environment, and the client ..."
>> to the end of this seciton, we can remove it.  Could you suggest me ?
>>
>>> 5.  Server Operation
>>>
>>>     After the DHCPv6 server receives a message which is contained an
>>>     Option Request Option, the information the server will provide
>>>     depends on local policy.  If there are no criteria on the server, the
>>>     following operation is RECOMMENDED.
>>>
>>> Nit: It is not entirely clear to me what you mean by "no criteria" above.
>>
>> I meant it should be policy of the server's behavior.
>> We replace the word like the following.
>>
>>    After the DHCPv6 server receives a message which is contained an
>>    Option Request Option, the information the server will provide
>>    depends on local policy.  If there is no local policy on the server, the
>>    following operation is RECOMMENDED.
>>
>>> idnits reports a DownRef to RFC 6251, but this was called out during
>>> IETF LC, so no problems here.
>>
>> Again, I apologize for my response.
>>
>> Best regards,
>> Shoichi
>