Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option
At first I thought that it might be good to leave section 4.1, but now I changed my mind. I think the order of the preference might depend on the running environment: some people prefer secured one, some people prefer DNS... So I'd like to make the order configurable and move section 4.1 to appendix, as a hint for implementation. masahiro On Wed, 27 Jun 2012 15:00:29 -0400, Sam Hartman hartmans-i...@mit.edu said: t == t p daedu...@btconnect.com writes: t Just to make public what I have hinted at privately, I think that steps t in section 4.1 may be somewhat underspecified. t A related issue is that section 4.1 prefers DNS to DHCP for Kerberos t information but the Security Considerations stress the weakness of t DHCP and recommend authenticating DHCP. What if DHCP is secure t and DNS is not? Should DNS still be preferred? Yes probably. DNS has been and will continue to be the dominant way to discover KDCs. I see this as a specialized DHCP option for certain deployments, not something you'll see in the enterprise for desktops or laptops as an example. I mean some people may deploy it, but I suspect that you won't see it in most situations where DNS works well today. So, basically in all cases, including preconfigured DNS servers, I'd expect DNS to be preferred. Note that choosing the right KDC does impact availability--if you have the wrong KDC it won't work. In general though, choosing the wrong KDC does not compromise authentication. It's a bit more complex than that, but KDC location has not generally been considered security sensitive.
Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option
t == t p daedu...@btconnect.com writes: t Just to make public what I have hinted at privately, I think that steps t in section 4.1 may be somewhat underspecified. t A related issue is that section 4.1 prefers DNS to DHCP for Kerberos t information but the Security Considerations stress the weakness of t DHCP and recommend authenticating DHCP. What if DHCP is secure t and DNS is not? Should DNS still be preferred? Yes probably. DNS has been and will continue to be the dominant way to discover KDCs. I see this as a specialized DHCP option for certain deployments, not something you'll see in the enterprise for desktops or laptops as an example. I mean some people may deploy it, but I suspect that you won't see it in most situations where DNS works well today. So, basically in all cases, including preconfigured DNS servers, I'd expect DNS to be preferred. Note that choosing the right KDC does impact availability--if you have the wrong KDC it won't work. In general though, choosing the wrong KDC does not compromise authentication. It's a bit more complex than that, but KDC location has not generally been considered security sensitive.
Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option
Original Message - From: ssakane ssak...@cisco.com To: t.p. daedu...@btconnect.com Cc: draft-sakane-dhc-dhcpv6-kdc-opt...@tools.ietf.org; sec...@ietf.org; ietf ietf@ietf.org Sent: Saturday, June 09, 2012 1:55 AM Removing the section 4.1 to an Appendix is nicer idea rather than just deleting it. Yes, but for me it is definitely second best. Arguably, following the steps in s 4.1 is necessary for interoperability. If DNS and DHCP produce the same KDC information, who cares what procedure is followed? It is only when they produce different results that the procedure matters. The dictum is that DNS information is preferred to DHCP information, but as the procedure shows, it is not quite that simple. It specifies that DNS is accessed via DHCP, ie DNS is only accessed if DHCP provides information about it. Without this guidance, an implementer might assume that eg preconfigured DNS information should be used to access DNS for KDC information rather than first asking DHCP for what it knows, in which case such an implementer would follow a different path to, potentially, a different KDC. So the client uses one KDC, the application server a different KDC; result, protocol failure. So you could see s 4.1 as necessary for the protocol to work. And again, as I said before, s 4.1 says that DNS SHOULD be used, while the Security Considerations say DHCP SHOULD be secured so given secure DHCP and insecure DNS giving different results, which SHOULD wins? Tom Petch Shoichi On 6/8/12 11:24 PM, t.p. daedu...@btconnect.com wrote: - Original Message - From: ssakane ssak...@cisco.com To: t.p. daedu...@btconnect.com Cc: draft-sakane-dhc-dhcpv6-kdc-opt...@tools.ietf.org; sec...@ietf.org; ietf ietf@ietf.org Sent: Friday, June 08, 2012 2:29 PM Hi Tom, Some reviewers suggested me to just remove the figure and its description in 4.1 because it has ambiguity. I think it would be better to leave the 1st paragraph in section 4.1, and I should remove the rest. What do you think about this idea ? I would leave it in. The first paragraph on its own I would think underspecified and the rest of the section does cover a number of issues, issues that only occurred to me when I read the section carefully. As I said in my last post, I then found I had further issues - how long to wait, should a secure DHCP trump an insecure DNS? - which may be worth exploring in addition. I do think that this kind of pseudocode helps a lot of developers to understand the issues and would want a good reason to remove it; at the same time, others see it as an impurity that has no part in a Standards Track RFC. One option would be to remove it to an Appendix which implicitly makes it Informative and not Normative so it is there for those who would benefit from it but will not upset those who consider it out of place. But I would bounce this off the krb list to see what reaction you get. Tom Petch Thanks, Shoichi On 6/8/12 7:37 PM, t.p. daedu...@btconnect.com wrote: Just to make public what I have hinted at privately, I think that steps in section 4.1 may be somewhat underspecified. They give the logic a client, one which supports both DHCP and DNS, should follow in order to find a KDC, with DNS information being preferred. One scenario outlined in section 1 is of a user having entered userid and passphrase and waiting to be authenticated. The steps imply a number of timeouts in succession without specifying what balance to take of how long to wait for a server to respond versus how long to keep the user waiting. I would find it difficult to know what balance to strike without guidance. A related issue is that section 4.1 prefers DNS to DHCP for Kerberos information but the Security Considerations stress the weakness of DHCP and recommend authenticating DHCP. What if DHCP is secure and DNS is not? Should DNS still be preferred? Tom Petch - Original Message - From: Jeffrey Hutzelman jh...@cmu.edu To: Samuel Weiler weiler+sec...@watson.org Cc: draft-sakane-dhc-dhcpv6-kdc-opt...@tools.ietf.org; sec...@ietf.org; ietf@ietf.org; jh...@cmu.edu Sent: Thursday, May 24, 2012 6:50 PM Subject: Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option
Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option
Just to make public what I have hinted at privately, I think that steps in section 4.1 may be somewhat underspecified. They give the logic a client, one which supports both DHCP and DNS, should follow in order to find a KDC, with DNS information being preferred. One scenario outlined in section 1 is of a user having entered userid and passphrase and waiting to be authenticated. The steps imply a number of timeouts in succession without specifying what balance to take of how long to wait for a server to respond versus how long to keep the user waiting. I would find it difficult to know what balance to strike without guidance. A related issue is that section 4.1 prefers DNS to DHCP for Kerberos information but the Security Considerations stress the weakness of DHCP and recommend authenticating DHCP. What if DHCP is secure and DNS is not? Should DNS still be preferred? Tom Petch - Original Message - From: Jeffrey Hutzelman jh...@cmu.edu To: Samuel Weiler weiler+sec...@watson.org Cc: draft-sakane-dhc-dhcpv6-kdc-opt...@tools.ietf.org; sec...@ietf.org; ietf@ietf.org; jh...@cmu.edu Sent: Thursday, May 24, 2012 6:50 PM Subject: Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option
Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option
On 6/8/2012 3:37 AM, t.p. wrote: Just to make public what I have hinted at privately, I think that steps in section 4.1 may be somewhat underspecified. They give the logic a client, one which supports both DHCP and DNS, should follow in order to find a KDC, with DNS information being preferred. Yes, this is because the DNS auth models are better than DHCP today AFAIK. One scenario outlined in section 1 is of a user having entered userid and passphrase and waiting to be authenticated. The steps imply a number of timeouts in succession without specifying what balance to take of how long to wait for a server to respond versus how long to keep the user waiting. True but this is likely to be set in the client as a flat config value one would think. And if so this is actually a good thing you bring up Tom. My take is that from a policy management standpoint the timeout period should be a policy level control IMHO and should have both a default value and a method of overriding it to allow people when they need to to create a more synchronous expectation from a responder. I would find it difficult to know what balance to strike without guidance. A related issue is that section 4.1 prefers DNS to DHCP for Kerberos information but the Security Considerations stress the weakness of DHCP and recommend authenticating DHCP. What if DHCP is secure and DNS is not? Should DNS still be preferred? DNSSEC is clearly beyond DHCP security models so perhaps for a working system this makes sense unless you want to create an autonomous DNS client which can exist in a pre-boot model. Pardon my restating the obvious but Still the issue is that DNS services dont work until they are loaded and DHCP is designed to work from a firmware boot (as we all know). How does this fit into what NEA is supposed to provide as a baseline? Tom Petch - Original Message - From: Jeffrey Hutzelmanjh...@cmu.edu To: Samuel Weilerweiler+sec...@watson.org Cc:draft-sakane-dhc-dhcpv6-kdc-opt...@tools.ietf.org; sec...@ietf.org;ietf@ietf.org;jh...@cmu.edu Sent: Thursday, May 24, 2012 6:50 PM Subject: Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option - No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.2178 / Virus Database: 2433/5055 - Release Date: 06/07/12
Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option
- Original Message - From: ssakane ssak...@cisco.com To: t.p. daedu...@btconnect.com Cc: draft-sakane-dhc-dhcpv6-kdc-opt...@tools.ietf.org; sec...@ietf.org; ietf ietf@ietf.org Sent: Friday, June 08, 2012 2:29 PM Hi Tom, Some reviewers suggested me to just remove the figure and its description in 4.1 because it has ambiguity. I think it would be better to leave the 1st paragraph in section 4.1, and I should remove the rest. What do you think about this idea ? I would leave it in. The first paragraph on its own I would think underspecified and the rest of the section does cover a number of issues, issues that only occurred to me when I read the section carefully. As I said in my last post, I then found I had further issues - how long to wait, should a secure DHCP trump an insecure DNS? - which may be worth exploring in addition. I do think that this kind of pseudocode helps a lot of developers to understand the issues and would want a good reason to remove it; at the same time, others see it as an impurity that has no part in a Standards Track RFC. One option would be to remove it to an Appendix which implicitly makes it Informative and not Normative so it is there for those who would benefit from it but will not upset those who consider it out of place. But I would bounce this off the krb list to see what reaction you get. Tom Petch Thanks, Shoichi On 6/8/12 7:37 PM, t.p. daedu...@btconnect.com wrote: Just to make public what I have hinted at privately, I think that steps in section 4.1 may be somewhat underspecified. They give the logic a client, one which supports both DHCP and DNS, should follow in order to find a KDC, with DNS information being preferred. One scenario outlined in section 1 is of a user having entered userid and passphrase and waiting to be authenticated. The steps imply a number of timeouts in succession without specifying what balance to take of how long to wait for a server to respond versus how long to keep the user waiting. I would find it difficult to know what balance to strike without guidance. A related issue is that section 4.1 prefers DNS to DHCP for Kerberos information but the Security Considerations stress the weakness of DHCP and recommend authenticating DHCP. What if DHCP is secure and DNS is not? Should DNS still be preferred? Tom Petch - Original Message - From: Jeffrey Hutzelman jh...@cmu.edu To: Samuel Weiler weiler+sec...@watson.org Cc: draft-sakane-dhc-dhcpv6-kdc-opt...@tools.ietf.org; sec...@ietf.org; ietf@ietf.org; jh...@cmu.edu Sent: Thursday, May 24, 2012 6:50 PM Subject: Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option
Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option
On Wed, 2012-05-23 at 19:12 -0400, Samuel Weiler wrote: With that said, there are some things that need clarification, and the doc sorely needs an editorial pass. As-is, the doc is not ready for publication. I will be happy to review the doc again once it's been thoroughly edited. It does need copy-editing. As far as I know, the IETF does not have a team of volunteer copy-editors, and multiple attempts to get help from within the working group have met with only limited success (most notably in the form of help from Stephen, who did quite a bit of work on this before starting on his AD review). If anyone wants to volunteer to spend some time on helping to clean up this document, let me know. Otherwise, I think our only options are either to ask the paid editors at the RFC production center to take a stab, or block an otherwise completed document on cycles that may never appear. Section 7 uses the term TGT without expansion. In the Kerberos world I can't imagine someone not knowing what this is, but it's not clear to the layman. It probably needs to be expanded. It does; I somehow missed that in my review. The algorithm in section 4.1 needs work. The obvious thing is to read it linearly. Doing that, one would prefer DHCP over DNS SVR info (per step 2), which is not what step 6 and the graphic say. The algorithm is fine, but the description requires careful reading. Step 2 kicks in only if you get a DHCP response containing Kerberos configuration but no nameservers. Saying no answer from the DNS server is probably not the desired semantic. There are only two branches here. Either you get a response containing one or more relevant SRV RRs, or you don't. The latter is phrased as no answer from the DNS server, but is meant to also include errors and empty responses. A suggestion for how to word this better would be welcome. In 3.4, the option-len field is ambiguous. It says 24-octet + the length of the realm-name field in octets. But it looks to me like this option is 27 octets + length of realm name. Perhaps it would be better to just count the length of the realm name? Yes, the description is wrong; the correct length is _23_ plus the length of the realm. The 16-bit option code and length are part of the DHCPv6 protocol; unless I'm misremembering, the length is the length of the option payload (that is, excluding the two header fields). Thanks for taking the time to review this. -- Jeff
