Subject: Re: [Ietf-krb-wg] DHCPv6 transport service option

From: Shoichi Sakane <[email-masked]>
Date: Wed, 05 Aug 2009 12:37:01 +0900

Hi Simon,

Yes, if this field is present, it is useful for a client for its
bootstrap.  I don't think it is harmful even if the field is present
as you said.  I would like to have this field if it is not harmful
for any client.

However, current KDC sub-option holds only a single service type
for an address of the KDC.  multiple KDC sub-options are needed
when the KDC supports several service types.  It is not good way.

I am thinking that a bitmap would be better.

Regards,

===
Shoichi Sakane

> Sakane-San,
>
> At the mic today I asked you that a number for TLS should be allocated
> in this table:
>
>    o  Service Type: the value of the type is defined in below.
>
>       Reserved 0
>       UDP      1 (default)
>       TCP      2
>       SCTP     3
>       HTTP     4
>       Reserved 5-15
>
> Leif pointed out that krb5starttls is run over TCP, so a type value for
> TLS is not really needed.  (I believe this was Leif's entire comment,
> correct me if I'm wrong.)  I didn't know how to respond.
>
> Having had a chance to think more about this, I see some value in having
> a number reserved for TLS: it allows clients to avoid having to spend
> one round-trip to find out the KDC does not support starttls.  That is a
> minor optimization, but since I also do not see any harm in having a
> value allocated, I think it makes sense to add it.
>
> If a TLS service type is present, the client saves one round-trip.  If
> the TLS service type is not present, and only the TCP type is present,
> the client cannot infer anything and could attempt to negotiate TLS.
>
> The high-level issue is of course whether the Service Type is useful at
> all.  I'm positive about it and would prefer to mirror the DNS SRV
> packet exactly and defer to RFC 4120 and RFC 2052 for the semantics.
>
> /Simon
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 05 Aug 2009 10:27:18 +0200

> as you said.  I would like to have this field if it is not harmful

Right.

> I am thinking that a bitmap would be better.

Good point.  I'm not sure a bitmap will work.  Wouldn't that force
admins to use the same IP address for their KDC-over-UDP, KDC-over-TCP,
etc?  The TLS SRV record allows admins to use different IP addresses for
a KDC reachable over TCP and UDP.  I think the DHCPv6 service type
option should allow the same.

The alternative is of course to allow admins to provide a list of KDC
addresses+service, much like the DNS SRV record.  What do you think?

Thanks,
Simon

---

From: Andrew Bartlett <[email-masked]>
Date: Wed, 05 Aug 2009 18:38:31 +1000

> option should allow the same.

It seems like a reasonable restriction to me - wouldn't allowing it just
be stringing out more than enough rope to hang the admins with?  Why
allow that flexibility?

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 05 Aug 2009 14:46:01 +0200

> be stringing out more than enough rope to hang the admins with?  Why

Because that flexibility is already present in the DNS SRV definition in
RFC 4120?  If someone is using that flexibility, they will find it
difficult to use this DHCPv6 option.  I note that, e.g., athena.mit.edu
have SRV records for UDP but no records for TCP.  That's not possible to
express in the DHCPv6 packet.

I don't care strongly, so I won't push this point further.

/Simon

---

From: Shoichi Sakane <[email-masked]>
Date: Thu, 06 Aug 2009 12:29:27 +0900

Hi,

Thank you for good input.  I have summarized this service type issue.

Providing service types
        If a TLS service type is present, the client saves one round-trip.
        If the TLS service type is not present, and only the TCP type is
        present, the client cannot infer anything and could attempt to
        negotiate TLS.
        If this field is present, it is useful for a client for its
        bootstrap.  It is not harmful even if the field is present.

Flexibility of the service type
        The DNS SRV records allow admins to use different IP addresses
        for a KDC reachable over TCP and UDP.
        In the 04 draft, a KDC sub-option holds a set of an address
        and a service type.  And the Kerberos option holds a set of
        KDC sub-options.  Flexibility is same to DNS SRV records.

Bitmap field vs Single value
        The KDC sub-option holds only a single service type for
        an address of the KDC.  Multiple KDC sub-options are needed
        when the KDC supports several service types.  It is not good way.
        A bitmap would be better.
        However, if the service types are expressed in a bitmap of a
        single field, it is difficult for a client to decide the order
        of the services.

How many service type should be defined ?
        UDP, TCP, SCTP, TLS over TCP

How many bits of the service type field is required ?
        8 bits for a single value,
        It depends on the number of service types to be defined.

===
Shoichi Sakane

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 06 Aug 2009 13:06:08 +0200

Leif Johansson <[email-masked]> writes:

> My only observation is that the same reasoning applies to any case
> of parameter negotiation and as long as you don't allow for negative
> parameters to be published over an insecure medium you should
> be fine, i.e "does-not-support-starttls" in DNS is bad since an attacker in
> control over DNS could fool the client "away" from using a feature 
> that would have added some additional measure of security.

I agree -- it is important that implementations do not treat absence of
information about a service type (be it TCP or UDP or TLS) as meaning
there is a preference of not using that particular service type.
Implementations should only use the information as an optimization or
hint, with reasonable fall-backs in case the information is wrong.

Of course, if the discovery information is provided through a trusted
mechanism (like DNSSEC), and if the implementation is configured to use
it, it is equally important that implementations do not fall back to
using an insecure discovery mechanism in case the DNSSEC discovery fails
for some reason (e.g., DoS).

I suspect these points are relatively clear from a specification
perspective though, and the problem is the complexity in getting it
right for implementers and admins.

/Simon

---

From: Leif Johansson <[email-masked]>
Date: Thu, 6 Aug 2009 12:49:16 +0200

> correct me if I'm wrong.)  I didn't know how to respond.

That was the entire point.

	Cheers Leif