Subject: [Ietf-krb-wg] AD review of draft-sakane-dhc-dhcpv6-kdc-option-13.txt

From: Stephen Farrell <[email-masked]>
Date: Sun, 22 Jan 2012 15:10:15 +0000

Hi,

My review is attached along with a version of the draft
with the many suggested editorial fixes.

I'll mark this as revised I-D needed.

I'd appreciate if drafts sent forward were better written
in future. I realise we face language challenges but
I would hope that the WG (who are proposing the document)
would help with those and not put the load onto the later
stages of the process.

That said, I also apologise for being so slow with this.
It took a while to get time to go over it and we were also
waiting in the hope of getting another WG participant to
help with the editorials.

Regards,
Stephen.

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 23 Jan 2012 14:30:46 -0500

On Sun, 2012-01-22 at 15:10 +0000, Stephen Farrell wrote:
> draft-sakane-dhc-dhcpv6-kdc-option-13
> 2012-01-22
> 
> Editorials, please see the suggestions in the attached. Use
> rfcdiff to see what's what, I just edited the .txt file (which
> was *much* quicker than writing up each of the *many* editorial
> changes).

Many thanks for taking the time to deal with this.

> - Is informational correct for this?

No; I called this out in my writeup.  We're asking that the draft be
published on the standards track, and the next version of the draft
should reflect this (authors, please make sure that happens).

> 
> - The last paragraph in section 2 is unclear - are you saying
> that "server" means a Kerberos principal that is a server to
> which a client wishes to authenticate? If so, say so.

The problem here is that sometimes "server" means a DHCPv6 server,
sometimes a Kerberos KDC, and sometimes a Kerberos application server.
Unfortunately, the rest of the text is not consistent in its use of
unqualified "server"; it often means a Kerberos application server, but
sometimes a KDC, and at least once a DHCPv6 server.

Note that the instant document does not describe a protocol in which any
authentication occurs, so "server" is never a server to which a client
is authenticating.  In cases where what is meant is a service principal,
the principal names a service about which a DHCPv6 client is requesting
information.

I think it would be best to remove this paragraph, and simply be
specific in every use of the word "server".

> 
> - If the options appear more than once in a DHCPv6 message, then
> what doess that mean?

A good question.

OPTION_KRB_PRINCIPAL_NAME and OPTION_KRB_REALM_NAME are intended to be
used by a client to hint as to what information it cares about.  It
probably doesn't make sense to include either of these options more than
once.

OPTION_KRB_DEFAULT_REALM_NAME configures the client's default realm;
this actually should not ever appear more than once.

So in fact, it only makes sense for OPTION_KRB_KDC to appear more than
once, in which case I think the behavior is reasonably well-defined -- a
client interested in contacting a KDC for a given realm should consider
all of the OPTION_KRB_KDC options providing KDC addresses for that
realm, and select among them according to the weight and priority fields
and the algorithm in RFC2782.

So, the statement in the beginning part of section 3, which states
"These options can appear multiple times in a DHCPv6 message", should
instead probably say "except for OPTION_KRB_KDC, none of these options
may appear more than once in a DHCPv6 message".

> - In which DHCPv6 messages can these options appear? (might be
> there later)

> - I don't get the 1st paragraph of 3.1 - what's this for,
> really?

It's for the client to indicate to the server its name, or the name of a
principal it's interested in.  Unfortunately, this has been going on for
a while, and I no longer remember why that's interesting.  Perhaps the
authors can remind us?

> - Why are noth 3.2 and 3.3 needed? I don't get that.

3.2 is for the client to indicate the name of a realm it's interested
in, so the server can use that information in selecting what to return.
We can't actually require that the server do anything with this, because
that would require that server behavior be affected by the option value
in ways that DHC does not want to mandate.  However, many servers do
provide the ability to tailor responses to the particular options sent
by the client, so 3.1 and 3.2 provide ways to convey information that
operators might want to use that way.

3.3 is for the server to tell the client what default realm to use.

> And why
> does 3.4 repeat the same information?

It doesn't.  The realm name in 3.4 is the realm served by the KDC
described in that option.  This option can appear multiple times,
describing multiple KDCs in multiple realms.

> - Is saying "follow rfc2782" enough in section 3.4? Which part
> of 2782 exactly?

RFC2782 doesn't have section numbers or the like, and a fairly
substantial fraction of the text is related to the Priority and Weight
fields and the description of a server selection algorithm.  I don't
know how to be more precise without just getting annoying.

It's worth noting that Kerberos client implementations are fairly likely
to already include weighted server selection along these lines, since
Kerberos already describes SRV RR support.  The expectation is that such
implementations will generalize a bit and use the same selection
algorithm in both places.

>  Later you say the client "could" use that, but
> in 3.4 you say MUST - you need to make those the same.

Yes; we need to say MUST everywhere.  Weak language like "could",
"might", or "if you want" doesn't really belong in a protocol
specification.

> - Point (8) on p10 is unclear - do you mean the client prefers
> DNS in this case?

Yes, I think the diagram is clear here -- KDC information from DHCP is
used only if no information is available from DNS.

> - The IANA request for Kerberos Message Transport Type is
> unclear, is that a new colum for an existing registry?

No, it's a new table, with initial values as given in 3.4, to be
included in the IANA "Kerberos Parameters" registry, 
http://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xml,
which currently contains some eight tables.

> - I don't know what is meant by "   The incorrect KDC is not be
> able to proceed any further state of the client." in the
> security considerations.

"Incorrect KDC" here is a fake KDC named in a modified DHCPv6 response.
A client could be led by an attacker to contact such a KDC, but the fake
KDC can't get anywhere because it doesn't know the client's key.

> - I have no idea what the 1st paragraph on p12 is meant to say.
> Please clarify.

This is a reference to a well-known attack on certain uses of Kerberos,
known as the "Zanarotti attack", originally described by Stan Zanarotti
at MIT back in the 1980's.  Basically, an attacker typing a Kerberos
password to log in to a machine can collude with a bogus KDC to gain
unauthorized access, if the software verifying the password does not
have a shared secret with the KDC and correctly use it to validate the
obtained tickets.

Describing this attack and how to defend against it in detail is out of
scope for the present document; however, it is appropriate to mention it
because the present document introduces a new way in which an attacker
might get a client to talk to a rogue KDC.

> 
> - Making DHCPv6 authenticaiton a SHOULD use means that this will
> not be used as I understand things. Do you really want that?

I'm not sure what "this will not be used" means.  Whether DHCPv6
authentication is actually used is a deployment decision, and thus not
something we can specify.  Here we RECOMMEND that its use be
implemented, so it will be available for those who wish to deploy it.
However, we also know that the feature will often not be used and that
there are use cases for very restricted (small) implementations, so
we're leaving room to leave it out.

> "...or any other authentication mechamism" is useless and should
> be deleted.

Agreed.

> - "tag" might need a reference - what does it mean? 

In the informative section A.4?  I don't think it needs a reference.
That section is telling you that in some industrial process systems,
things are identified by something called a "tag" instead of by a domain
name.  It doesn't really matter what a "tag" is; what matters is that
such environments don't use the DNS at all, and so it's not available to
serve as a KDC discovery mechanism.  In context, I don't think we need
more reference to the architecture of those environments than is already
provided in A.6.

-- Jeff

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Jan 2012 22:40:34 +0000

Hi Jeff,

Thanks for that - I'm ok with all your responses except
I'm still not clear if the document needs to explicitly
specify the DHCP messages in which these options can
appear. (I'm ok if you say "nope," I just want to check.)

Cheers,
Stephen.

PS: And sorry for being narky about the editorials, I
was in an airport doing this which didn't help:-)

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 23 Jan 2012 18:02:48 -0500

> appear. (I'm ok if you say "nope," I just want to check.)

Oh; I forgot to fully address that.
I'm not sure what the current wisdom on this is, but hopefully the DHC
chairs (whom I've bcc'd) will chime in and tell us.  My take is that we
probably do want to point out that OPTION_KRB_PRINCIPAL_NAME and
OPTION_KRB_REALM_NAME are intended to be sent by clients to hint as to
what information they need, while OPTION_KRB_DEFAULT_REALM_NAME and
OPTION_KRB_KDC are intended to be sent by DHCPv6 servers to provide
Kerberos configuration parameters to the DHCPv6 client.

However, we certainly do not want to specify that particular options are
sent in specific DHCPv6 messages.  Doing that would unnecessarily bind
this spec to the current state of DHCPv6, with the risk that it would be
unusual or do the wrong thing in the presence of some as-yet-unforeseen
change or extension to DHCPv6.

-- Jeff

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Jan 2012 07:57:48 +0000

On Jan 24, 2012, at 12:02 AM, "Jeffrey Hutzelman" <[email-masked]> wrote:

>  My take is that we

This is exactly right.