Subject: [Ietf-krb-wg] DHCP option discussion

From: Sam Hartman <[email-masked]>
Date: Tue, 17 Mar 2009 12:22:43 -0400

I have not seen Jeff respond to the request for agenda time to discuss
the DHCPV6 option.  I don't know if he's waiting for comments, but if
so, I support that discussion.

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 17 Mar 2009 12:38:53 -0400

> so, I support that discussion.

No, I forgot to respond.

Shortly after the last meeting, I sent a message to this list summarizing 
my discussion with Ralph Droms and asking for discussion on the question of 
whether to adopt the document.  Aside from Shoichi's thanks for raising the 
question, there were no responses.

I'm happy to add an item to the agenda if it will benefit from the use of 
scarce face-to-face meeting time, but that seems unlikely in this case.  I 
probably will poll the room in order to get an idea for how people feel 
about adopting this, but I don't see that there's anything to discuss.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Tue, 17 Mar 2009 12:57:21 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> No, I forgot to respond.

    Jeffrey> Shortly after the last meeting, I sent a message to this
    Jeffrey> list summarizing my discussion with Ralph Droms and
    Jeffrey> asking for discussion on the question of whether to adopt
    Jeffrey> the document.  Aside from Shoichi's thanks for raising
    Jeffrey> the question, there were no responses.

While I did not respond to your message directly, I did say that if
they fixed the problems with their optione I thought it was a good idea.

The problems were basically the assumption that you would only be
giving information for one realm.  I think the problem may be more
with the text than with the actual protocol formats.

---

From: Shoichi Sakane <[email-masked]>
Date: Wed, 18 Mar 2009 17:07:58 +0900

Hi Sam,

Thanks for putting this discussion on the table again.  The following
URL is the new revision of the draft which includes Sam's idea, which
specifies whether the realm option is for default or not.

http://www.ietf.org/internet-drafts/draft-sakane-dhc-dhcpv6-kdc-option-04.txt

I am happy to discuss my proposal with you in somewhere in the next meeting
venue.  I want to know if my modification satisfy you.

Best regards,

===
Shoichi Sakane

---

From: Sam Hartman <[email-masked]>
Date: Wed, 18 Mar 2009 09:26:47 -0400

I've briefly reviewed the new draft.

I would support work based on this protocol approach within the WG.  I
have time to provide reviews, but not to contribute text.

I think the protocol described is reasonably sound although I think
some more explanatory text is needed on what a client should do with
the default realm 0 case.  Since, we in the Kerberos working group
asked for that, it seems reasonable we should provide that text.

I have some input on section 6.

I recommend not including the special Cable Labs options which I believe are discussed in 6.2.  I think the architecture will be cleaner without this.

I recommend only supporting IPV6 addresses with this option.  That is
consistent with how DHCPV6 is designed.  I think that may have been a
bad design choice, but it is not our place to redesign DHCPV6.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Leif Johansson <[email-masked]>
Date: Thu, 19 Mar 2009 13:23:04 +0100

> venue.  I want to know if my modification satisfy you.

In section 3.1 it isn't clear if you are going for normative language or not, 
i.e should it be SHOULD...? Also, are you sure it is always better to trust
DNS over DHCP? Given that there are various proposals for DHCP 
auth and the fact that in many enterprise environments it is more difficult
in practice to mount a MITM attack on DHCP than on DNS.

	Cheers Leif

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 Mar 2009 17:31:50 -0400

Yeah, I'll admit that I would have assumed you wanted to trust DHCP in preference to DNS at least for determining KDC addresses.

It's not much of a security issue: denial of service is the only concern there.
I think the main question is whether DNS or DHCP will have more accurate configuration.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nobuo Okabe <[email-masked]>
Date: Fri, 20 Mar 2009 19:46:22 +0900

Hi all,

Sorry for not respond quickly.

I cannot attend the meeting.
But, I'll help Shoichi to improve the draft
as much as I did:

   Subject: [Ietf-krb-wg] reasons of DHCP-based KDC discovery
   From: Nobuo OKABE <[email-masked]>
   Date: Thu Jul 31 2008 23:34:44 GMT+0900 (JST)

Thanks,

---

From: KAMADA Ken'ichi <[email-masked]>
Date: Fri, 20 Mar 2009 17:57:00 -0500

At Tue, 17 Mar 2009 12:38:53 -0400, Jeffrey Hutzelman wrote:
> 
> I probably will poll the room in order to get an idea for how people feel 

I would like to see a standardized method to distribute
realm/KDC-address information via DHCP.  According to Jeff's previous
mail, DHCP options are usually defined by domain-specific expertise
before reviewd by DHC WG, so I am for adopting this work in this WG.

Ken'ichi

---

From: KAMADA Ken'ichi <[email-masked]>
Date: Fri, 20 Mar 2009 23:41:06 -0500

> venue.  I want to know if my modification satisfy you.

Section 2.1 defines the default realm bit.
I know MIT krb5 and Heimdal have the default realm and I guess
other implementations also do.
>From specification point of view, however, RFC 4120 does not
define it as far as I know.
It may be worth clarifying what the default realm is.

*  For what the default realm is used?
   Is it used when a client does not know its own realm?
   Is it used when a client does not know servers' realms?

*  Is it safe to unconditionally accept the default realm from DHCP
   (or other external service)?

*  If an implementation does not have the concept of the default realm,
   what should it do upon receipt of this bit?

*  What does it mean if multiple realms have the default realm bits?
   Is it just invalid?

-- 
Ken'ichi

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 20 Mar 2009 23:54:02 -0500

> It may be worth clarifying what the default realm is.

Great point!

>    Is it used when a client does not know servers' realms?

It's used primarily for:

 - determining the realm of a user principal derived from a username
   that has no domain qualifier of any kind;

 - as a fallback when it is not possible to determine a host's realm in
   any other way;

But there may be other uses for a default realm.  For example, if a
system has a keytab with entries for principals from multiple realms,
which one should be used when acting as a Kerberos V client in a context
where a client principal name to use is not known?  E.g., when accessing
secure NFS/AFS/CIFS/... resources using host credentials -- if the
access results from a POSIX system call then there's no direct way to
specify which keytab entry's principal name to use as the client
principal.

>    (or other external service)?

It is not exactly safe.  The threat model here matters.

For example, if off-line dictionary attacks on PA-ENC-TIMESTAMP are
considered a problem then the DHCP client MUST NOT use the default realm
from DHCP for username->principal name derivation.

>    what should it do upon receipt of this bit?

It should ignore it.

> *  What does it mean if multiple realms have the default realm bits?

That should probably be considered an error.  What the client response
to that should be, I don't know.

Nico

---

From: Sam Hartman <[email-masked]>
Date: Sat, 21 Mar 2009 12:01:20 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:
    Nicolas>  - as a fallback when it is not possible to determine a
    Nicolas> host's realm in any other way;

I'd agree with this for the local host.  I think it is inappropriate
to use the default realm to determine the realm of some other host.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Shoichi Sakane <[email-masked]>
Date: Mon, 23 Mar 2009 01:32:14 +0900

> from DHCP for username->principal name derivation.

I actually assumed the environment which is described in section 1.6 of RFC1420.
However, I will add this case to the section of security consideration.
This case should be especially considered in the case of providing a default realm
from a DHCP server because an attacker could lead an user to the malicious KDC
which obtained a password of the user.

I think the success of this attack depends on the following properties:
1. difficulty of breaking a password by off-line dictionary attack.
2. difficulty of providing invalid information from any host.
Kerberos basically does not provide those properties.  To prevent the attack,
other technique like network monitoring must be used.

>>    what should it do upon receipt of this bit?

I agree with the behavior.
I think an implementation, which has an capability of processing
the kerberos option for DHCP, always process the default realm bit.
If the host does not need to handle the bit, the host MUST be ignore it.
I will add a text.

> to that should be, I don't know.

I thought so.  I have to add a text.

Thanks.

---

From: Shoichi Sakane <[email-masked]>
Date: Sun, 22 Mar 2009 10:06:29 -0700

On 03/19/2009 05:23 AM, Leif Johansson wrote:
> i.e should it be SHOULD...? 

I didn't think the text would not be for normative.  I will fix it.

Is the following text O.K ?
    When a client has capabilities of both the DNS method defined by RFC 4120
    and the DHCP method defined by this document,
    which methods the client adopts depends on the policy of the environment.

> Also, are you sure it is always better to trust

No, I don't think DNS is always better way than DHCP.  In this section,
I just wanted to describe a way to get information from servers in the
point of view of compatibility of RFC 4120.
I would like to hear any opinions from everybody about this section.

Thanks.

---
Shoichi Sakane

---

From: Shoichi Sakane <[email-masked]>
Date: Sun, 22 Mar 2009 11:03:28 -0700

Hi Sam,

> have time to provide reviews, but not to contribute text.

Any help would be appreciated to me!  Thank you.

> asked for that, it seems reasonable we should provide that text.

when a client doesn't know a realm for itself AND a DHCP server
doesn't provide a realm name as a deafult, it must be something
configuration error in the environment.  I think that the
administrator has to know that such client may exist in its network.

> I recommend not including the special Cable Labs options which I believe are discussed in 6.2.  I think the architecture will be cleaner without this.

Yes, if we don't need to think about the special Cable Labs options,
it becomes simple.  I don't know how much it will impact to the architecture.
I would like to be out of scope.

> bad design choice, but it is not our place to redesign DHCPV6.

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

---

From: Shoichi Sakane <[email-masked]>
Date: Sun, 22 Mar 2009 11:14:23 -0700

> to use the default realm to determine the realm of some other host.

Could you tell me why it is inappropriate for a client to use the default realm
to determine the realm of some other host ?
When a client knows only the printer server's name and doesn't know
its realm, I think that it is reasonable to use the default realm
for the printer, which the default realm was for the client's.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Masahiro =Rhythm Drive= Ishiyama <[email-masked]>
Date: Mon, 23 Mar 2009 17:12:16 +0900

I'm sorry that I cannot attend the meeting, but I'd be really
	happy if the WG thought that the draft would be beneficial.

>>>>> On Sun, 22 Mar 2009 10:06:29 -0700, Shoichi Sakane <[email-masked]> said:
 > 
>> In section 3.1 it isn't clear if you are going for normative
>> language or not, i.e should it be SHOULD...? 
 > 
>> DNS over DHCP? Given that there are various proposals for DHCP auth
>> and the fact that in many enterprise environments it is more
>> difficult

	Right. I also don't think DNS is ALWAYS better to trust. But I
	don't want to break current client behavior even if the DHCP
	support is introduced. I really appreciate your comments.

regards,

Masahiro Ishiyama

---

From: Martin Rex <[email-masked]>
Date: Mon, 23 Mar 2009 16:25:13 +0100 (MET)

Shoichi Sakane wrote:
> Could you tell me why it is inappropriate for a client to use the
> default realm to determine the realm of some other host ?

AFAIK, the "default realm" refers to the entry "default_realm" in the
[libdefaults] section of krb5.conf in the traditional (MIT) Kerberos 5
configuration, whereas the mapping of DNS-Names of hosts into Kerberos
realms is performed through mappings in the section [domain_realm].

Microsoft Kerberos also supports such a domain_realm mapping
through the Registry
   "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\HostToRealm"

So the question with respect to that DHCPv6 option looks to me more
like "should we abuse the default_realm" when DHCPv6 is used, rather
than "how can we distribute the HostToRealm mapping" when DHCPv6
is used.

How much of the Kerberos configuration should be "outsourced" to
DHCP(v6)?  What are the security implications of doing this?

-Martin

---

From: Shoichi Sakane <[email-masked]>
Date: Mon, 23 Mar 2009 13:51:57 -0700

> than "how can we distribute the HostToRealm mapping" when DHCPv6

I don't want to force a host to use a default realm from a DHCP sever.
If a host has a mapping table, the host should prefer to use it.

On the other hand, if a host need the mapping table like HostToRealm,
and there is no mechanism to provide it.  DHCP might be used to do so.
But, you need to consider security impacts on your environment.

> DHCP(v6)?

I currently define only three sub-options, which are enough for my
scenario that was essentially explained by the following mail.

If you have something information to be provided from DHCP,
please let me know.  I would like to consider to add it to the draft.

> What are the security implications of doing this?

I don't want to break security provided by Kerberos.  I mainly want to
provide bootstrapping information to a host with compatibility to
current specification.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Luke Howard <[email-masked]>
Date: Tue, 24 Mar 2009 09:17:55 +1100

Would it not be preferable to use referrals (always request the  
"default" realm and allow the TGS to direct the client to the  
appropriate realm).

-- Luke

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 23 Mar 2009 16:08:09 -0700

> "default" realm and allow the TGS to direct the client to the  

For some enviroments this is very true since [domain_realm] or  
HostToDomain doesn't scale.

Love

---

From: Shoichi Sakane <[email-masked]>
Date: Tue, 24 Mar 2009 08:28:40 -0700

> "default" realm and allow the TGS to direct the client to the 

I don't think it is better to define priority of referrals and dhcp
at this time.  It will depend on user's environment.

It will be of benefit in Client Referrals.  I can imagine the case
when a host does not know a realm itself which is used to send an AS-REQ.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Mon, 23 Mar 2009 20:03:14 -0400

>>>>> "Luke" == Luke Howard <[email-masked]> writes:

    Luke> Would it not be preferable to use referrals (always request
    Luke> the "default" realm and allow the TGS to direct the client
    Luke> to the appropriate realm).

Referrals do not go to the default realm.  They go to the realm of the
client principal.

The reason I'm uncomfortable for default_realm being used for
host-to-realm mapping directly is that currently default_realm is an
untrusted quantity.  The client needs to trust the host-to-realm
mapping.  I understand this is a bit subtle in the case where the
default realm is used to generate the client principal.  However I
believe the distinction important.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 23 Mar 2009 19:07:06 -0700

Agree that referrals are preferable to [libdefaults] default_realm.

> believe the distinction important.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 24 Mar 2009 09:51:47 -0700

--On Tuesday, March 17, 2009 12:38:53 PM -0400 Jeffrey Hutzelman 
<[email-masked]> wrote:

> my discussion with Ralph Droms and asking for discussion on the question
> of whether to adopt the document.  Aside from Shoichi's thanks for
> raising the question, there were no responses.
>
> scarce face-to-face meeting time, but that seems unlikely in this case.

Based on this discussion I've seen, I'm planning on taking a poll at this 
afternoon's meeting to gauge support for adopting this work.  Assuming 
Shoichi Sakane is here this week (or on Jabber), I'll give him an 
opportunity to answer any questions that people feel they need to ask in 
order to decide whether to support adopting the work.  However, we will not 
have a presentation on this work, and we won't spend any time debating its 
technical details; I think we've done enough of that to make a decision, 
and we don't have the meeting time for it.

If we decide we want to adopt the work, then Larry and I will talk to Tim 
about getting our charter amended to include it.

-- Jeff

---

From: Shoichi Sakane <[email-masked]>
Date: Wed, 25 Mar 2009 03:08:26 +0900

> Based on this discussion I've seen, I'm planning on taking a poll at 
> this afternoon's meeting to gauge support for adopting this work.  
> Assuming Shoichi Sakane is here this week (or on Jabber), I'll give him 
> an opportunity to answer any questions that people feel they need to ask 
> in order to decide whether to support adopting the work.  However, we 
> will not have a presentation on this work, and we won't spend any time 
> debating its technical details; I think we've done enough of that to 
> make a decision, and we don't have the meeting time for it.
> 
> If we decide we want to adopt the work, then Larry and I will talk to 
> Tim about getting our charter amended to include it.

Thank you for giving me a chance.  I am here, and I am going to join the meeting.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Shoichi Sakane <[email-masked]>
Date: Wed, 25 Mar 2009 03:31:53 +0900

> specify which keytab entry's principal name to use as the client

Currently, it seems that we have three different usage of default realm.
1. determining the realm of a user principal derived from a username
   that has no domain qualifier of any kind.
2. as a fallback when it is not possible to determine a host's realm in
   any other way.
3. determining a user principal name on the list of multiple principals
   with multiple realms.

Do you think that a common usage of "Default Realm" should be
described into this document ?  I think it is better to be
in another document about this, but I admit that I need to 
describe short text about handling the default realm and
relationship between dhcp, local configuration and referrals.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg