Subject: RFC4120

From: [email-masked]
Date: Thu, 15 Jun 2006 17:29:34 -0400

All

What is the status of RFC 4120?  Is it final?

I have a case where someone is citing RFC 4120 as the authority.

Thx Ron Durbin

---------------------
[email-masked]
EMC² NAS Engineering
---------------------

---

From: Ken Raeburn <[email-masked]>
Date: Thu, 15 Jun 2006 18:14:38 -0400

> What is the status of RFC 4120?  Is it final?

I'm not quite sure what you mean.  We've got some updates planned for  
a new RFC, but 4120 is done and published as an IETF Proposed  
Standard, as of almost a year ago.  It should be perfectly reasonable  
to use it as a basis for other work.  (Though things like i18n  
support aren't present in this version.)  People should *not* be  
using RFC 1510 as the basis for any new Kerberos-related work.

Or are you concerned about the planned updates?  I think they'll be a  
while in coming.

> I have a case where someone is citing RFC 4120 as the authority.

Glad to hear it. :-)

Ken

---

From: Martin Rex <[email-masked]>
Date: Mon, 19 Jun 2006 23:25:45 +0200 (MET DST)

> I have a case where someone is citing RFC 4120 as the authority.

As an authority for what?

It is an authority for what new _implementations_ should look like.
It is not an authority for what existing implementations or
an installed base looks like.

The only pressure on the installed base to update to rfc-4120
is "market pressure", there is *NO* normative pressure of any kind.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 19 Jun 2006 17:13:07 -0500

> an installed base looks like.

RFC4120 obsoleted RFC1510 and is a better description of what
pre-RFC4120 Kerberos V implementations do than RFC1510.

> is "market pressure", there is *NO* normative pressure of any kind.

True, the IETF does not have force of law and cannot impose standards on
an unwilling world.  That said, the market pressure to adopt RFC4120 is
sufficiently strong that it is being adopted.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 21 Jun 2006 13:44:51 -0400

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    >> I have a case where someone is citing RFC 4120 as the

    Martin> As an authority for what?

    Martin> It is an authority for what new _implementations_ should
    Martin> look like.  It is not an authority for what existing
    Martin> implementations or an installed base looks like.

I have to agree with Nico that RFC 4120 is a far better description of
what today's installed bases do look like that RFC 1510.

Notable differences include support for AES which is mandated by RFC
4120, but which will not be hugely common until Windows Vista ships.
MIT, Heimdal, Solaris and Apple have had AES for a hile now, though.

---

From: "Shawn M. Emery" <[email-masked]>
Date: Wed, 21 Jun 2006 12:28:03 -0600

> MIT, Heimdal, Solaris and Apple have had AES for a hile now, though.

There are a number of implementations that don't enforce requirements 
made by RFC 4120.  For example:

   Implementations of Kerberos and protocols based on Kerberos MUST NOT
   use insecure DNS queries to canonicalize the hostname components of
   the service principal names (i.e., they MUST NOT use insecure DNS
   queries to map one name to another to determine the host part of the
   principal name with which one is to communicate).

Shawn.
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 21 Jun 2006 13:52:04 -0500

So the question was, "is RFC4120 authoritative?" and Martin added "for
what?"

The answer is:

RFC4120, along with RFCs 3961 and 3962, is the normative description of
the Kerberos V protocol, and this includes pre-RFC4120 Kerberos V,
except for different requirements (e.g., RFC4120 requires, in the
RFC2119 sense, support for AES, whereas RFC1510 requires only 1DES,
which, in any case, is all it specified).  If you're an implementor this
means that these are the RFCs you want to read: RFC3961, RFC3962 and
RFC4120; you could also read RFC1510, but don't have to.  If you're not
an implementor, and simply need a normative reference to the Kerberos V
network authentication protocol, then RFC4120 is it.

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 Jun 2006 01:02:16 +0200 (MET DST)

>    principal name with which one is to communicate).

Good observation.  While this requirement is a good idea, MIT Kerberos
has been running for very very long time with insecure DNS canonicalization,
and I don't know if or when the MIT codebase has been changed in this
detail.  I complained about insecure DNS canonicalization of hostbased
service names in Kerberos and GSS-API v2 on the CAT mailing list since 1997,
and MIT Kerberos 1.1 (1999) still performs insecure lookups.

While rfc4120 might be more detailed about some implementation
(and therefore interoperability) details, it might be misleading
in some places such as the one you cite about what can be considered
normative for the installed base.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 Jun 2006 01:17:10 +0200 (MET DST)

followup to myself:

> >    principal name with which one is to communicate).

While the requirement for secure DNS is good in theory, it entirely
ignores the reality.  In the real world, secure DNS is still far from
widespread use.   There is no guidance what to do in the majority
of real world environments without secure DNS.  Do current implementations
reveal their particular "conformance level" to the user?  Should
implementations offer a possibility for the user to entirely disable
DNS lookups that are not guaranteed to come from secure DNS?

A sensible approach might have been what ssh is doing when connecting
to a previously unknown host: ask the user whether the fallback to
an insecure canonicalization to a particular (visualized) hostname
is ok (and have it cached/memorize the user-acknowledged insecure
canonicalization result).

This is an Email that I sent to the ietf-cat mailing list in 1997:
:
:   From:    Martin Rex <[email-masked]>
:   Subject: Re: FW: Revisions to Kerberos RFC
:   To:      [email-masked] (Dennis Glatting)
:   Date:    Wed, 30 Jul 1997 11:58:23 -0400 (EDT)
:   Cc:      [email-masked]
:
: Dennis Glatting wrote:
: >
: > As I said previously, not coupling (or disallowing) DNS or other resolution
: > mechanisms in the formation of principals will have an impact on existing
: > applications. What I didn't say was examples. Some examples include
: > Kerberized telnet, r utilities, and possibly KPOP. With telnet, for
: > example, how will a principal be formed when only a portion of the host's
: > name is supplied? Are we going to force telnet users to type the FQDN for
: > local hosts as well as remote hosts? We could, but that's isn't going to be
: > very popular and may even hurt Kerberos. We could require a well maintained
: > krb.realms file but, as we all know, that isn't manageable in the large and
: > diverse.
: 
: Since the name transformation is done before looking at krb.realms
: this doesn't really help.  The most vital part of the principal name
: can be replaced by spoofing a CNAME into the DNS lookup.  The more
: service keys are installed on the machines of a realm, the more
: likely it is that an attacker can get access to one such key and
: use it to impersonate a service instance by spoofing the hostname
: part.  Since host keys are most likely to exist on all machines of a
: realm, it is the most vulnerable service.
: 
: >
: > I realize the problems with relying on resolution mechanisms but I believe
: > it is a necessary evil, less so in the presence of DNSsec. Wrt Mike Swift,
: > SHOULD in lieu of MUST seems like a reasonable compromise.
: 
: I don't think that DNSsec is a valid excuse for at least two more years.
: As long as software only uses gethostbyname(), it is not able to realize
: presence of DNSsec or distinguish secure from non-secure answers, and
: for interoperability, insecure DNS-lookups on the internet will have to
: be accepted for quite some time to come.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 21 Jun 2006 18:52:29 -0500

On Thu, Jun 22, 2006 at 01:17:10AM +0200, Martin Rex wrote:
[talking about DNS canonicalization of hostnames]
> canonicalization result).

There are other sensible things to do.

Users primarily want/expect hostname canonicalization to applly DNS
resolver search lists to figure out what a FQDN corresponds to a
short-form name entered by the user.

Given this, then, a krb5 mechanism's GSS_Canonicalize_name() (if only it
had an input_credential_handle!) or GSS_Init_sec_context() might, in KSH
pseudo-code:

canon_host_princ ()
{
	typeset princ user_entered_princ
	user_entered_princ=$1
	for domainname in "" $resolver_search_list
	do
		if [[ "$domainname" != "" ]]
		then
			princ=${user_entered_princ}.$domainname
		fi

		if try_to_get_ticket_for $princ
		then
			print $princ
			return 0
		fi
	done
	return 1
}

Note that because KRB-ERROR messages are never integrity protected
(pre-extensions) an attacker can always force the client to fall through
its search list.

Note also that this doesn't deal with aliases, but hosts could have
principals for each of their official aliases.

Note further that this applies to other mechanisms that might
authenticate services by their FQDNs, such as PKIX mechanisms.

Applications should know whether canonicalization has been done
securely, and if not whether they could have been subject to any attack
beyond the search list fallthrough attack I described.  Then they can
present the user with "appropriate" ssh-like questions.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 Jun 2006 02:45:09 +0200 (MET DST)

> There are other sensible things to do.

I'm sorry, I intended to NOT preclude other approaches.
Maybe I should have started with "one" instead of "a".

But when looking at how MIT Kerberos5 has traditionally employed
"gethostbyname()" to canonicalize a name, then it did not use
DNS lookups to _only_ tack on a domain -- it always used it to
fully canonicalize the entire hostname, and that was considered
a desirable feature.

The use of DNS CNAME records to map a "generic" service (like
the web-server or ftp-server of a company to a particular host)
is extremely common.  And we even have installations where the
DNS answer to a canonicalization will change with every request
for load balancing purposes!

Btw. a domain search list might be a security problem by itself for the
canonicalization -- the more the longer it is.

There was an interesting discussion about canonicalization
of the hostnames in hostbased service names on the cat-ietf mailing
list in 1999, but it is a little long to quote here.  e.g.

:   From:       Ken Raeburn <[email-masked]>
:   To:         Jonathan Trostle <[email-masked]>
:   Cc:         "Paul Leach (Exchange)" <[email-masked]>,
:               [email-masked],
:               "Mike Swift (NT) (Exchange)" <[email-masked]>
:   Date:       08 Dec 1999 00:26:23 -0500
:   Subject:    Re: comments on krb-dns-locate draft
:   Message-ID: <[email-masked]>

Interesting in that it mentioned many ways of canonicalization in
active use and motivations behind it.

> present the user with "appropriate" ssh-like questions.

In reality, neither kerberos nor other gssapi implementations have a way
of telling the application what (a) they can and (b) what they do when
processing hostbased service names.  And as I mentioned, GSS-API v2
(rfc-2743) suggests canonicalization through (insecure) DNS.
There is no way for portable GSS-API based apps to figure out what
was done, and IMHO applications should NOT have to care.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Wed, 21 Jun 2006 20:18:53 -0400

MIT Kerberos is still broken in this regard.  MIT does consider this
an important issue to fix, but we need to provide KDC-level aliasing
before it makes sense to do so.

I'm sorry that we did not listen to you in 1997.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 21 Jun 2006 21:30:19 -0400

On Thursday, June 22, 2006 01:17:10 AM +0200 Martin Rex 
<[email-masked]> wrote:

> While the requirement for secure DNS is good in theory

There is no such requirement.  The requirement is that _insecure_ DNS must 
not be used to derive principal names.  It is fine to use secure DNS, but 
it is also fine to use techniques which do not rely on the DNS at all.  For 
example, you could use the name the user typed, or one derived by 
concatenating the name the user typed with a domain name obtained from a 
trusted source (for example, local resolver configuration).  In fact, I 
think the document even suggests this approach.

Incidentally, this is _not_ the same as what ssh clients do.  What ssh 
clients do when connecting to a host they've not connected to before is 
print the host's key, or a hash thereof, and ask the user if it is OK. 
There is no way the user can answer that question without knowing the 
correct key (or hash) in advance and comparing it bit-for-bit.  I have yet 
to see an ssh client which, when I say "ssh foo", resolves foo to 
foo.example.com, establishes a connection to that, and then says "I don't 
know the host key for foo, but I have one for foo.example.com which matches 
the host I connected to; is that OK?".  I agree that would be a valuable 
feature for ssh clients to have, and it might make sense in some Kerberos 
applications as well.

Also, it is worth noting that the text Shawn quotes requires that Kerberos 
implementations not use insecure DNS to derive principal names, and it 
requires that Kerberos application protocols not do so.  It does _not_ 
require Kerberos implementations to "enforce" this requirement, only to 
comply with it.

Martin, I wasn't involved in the IETF 10 years ago, but if I had been, I'd 
like to think I'd have been standing right next to you arguing for this 
requirement then.  It took a little longer to get it in there than it 
should have, but we did eventually get it right.

-- Jeff [not as chair]

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 21 Jun 2006 21:44:16 -0500

> Maybe I should have started with "one" instead of "a".

I did not mean to imply you had.  I merely wanted to describe this
alternative.

> fully canonicalize the entire hostname, and that was considered

Yes, I'm aware.

Aliasing can be handled by just giving hosts principals for all their
aliases (or at least the ones users will use).

Short-form-to-FQDN canonicalization, OTOH, cannot be handled in the same
way.

> canonicalization -- the more the longer it is.

Yes.  Fortunately people don't usually use long search lists.

Typical search lists look like:

search foo.bar.com bar.com

> list in 1999, but it is a little long to quote here.  e.g.

Yeah.

> processing hostbased service names.

The APIs aren't rich enough.

GSS_Canonicalize_name() could take a credential handle and output some
flags indicating how secure the canonicalization process was.  Then the
applications could prompt users.

>                                      And as I mentioned, GSS-API v2

We're here (well, in the KITTEN WG) to specify extensions to the
GSS-API :) :-)

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 22 Jun 2006 11:52:37 +0200

>   principal name with which one is to communicate).

There are several other examples:

1) Nobody else's implementation that I've tested seem to behave
   according to RFC 4120 wrt to the high bit set on TCP connections.

2) W2k3 and heimdal has problems with session keys in a TGS-REQ [1]

3) Heimdal sends a non-standard ETYPE-INFO [2].

/Simon

[1] http://article.gmane.org/gmane.comp.gnu.shishi.general/195
    (there's a bug work around for Heimdal, that's why it's labeled "works")
    http://article.gmane.org/gmane.comp.gnu.shishi.general/175
[2] http://article.gmane.org/gmane.comp.gnu.shishi.general/90

---

From: Marcus Watts <[email-masked]>
Date: Thu, 22 Jun 2006 07:05:13 -0400

> 3) Heimdal sends a non-standard ETYPE-INFO [2].
...
> [2] http://article.gmane.org/gmane.comp.gnu.shishi.general/90
...

Interesting...

heimdal has this in lib/asn1/k5.asn1

ETYPE-INFO-ENTRY ::= SEQUENCE {
        etype[0]                ENCTYPE,
        salt[1]                 OCTET STRING OPTIONAL,
        salttype[2]             INTEGER OPTIONAL
}

which is indeed not part of section 5.2.7.4 of RFC 4120.
On the other hand, since salttype is optional, it's certainly
*possible* for them to return comformant results.

Presumably this change is because etype_info as originally defined can't
handle all salt types, so there are certain cases where it simply won't work.
The cleanest approach would be to return only etype_info2 data for
such entries - but that assumes clients that can handle etype_info2.
The heimdal folks presumably figured it was better to extend
etype-info in a way that allowed smart clients to actually work,
than to return the wrong thing or nothing at all which would result
in a situation that can't be fixed from the client side.  This
is mostly an issue with "afs3" salt - all the other standard des salt
types can be described completely by the salt string itself.

On the other hand -- at least in the heimdal source I have handy (0.6.4)
I don't see logic to allocate and return salttype if and only if afs3 salt
is there.  Assuming I'm following this logic right, they didn't quite
follow through on making it right for cases where they presumably could
have.  Perhaps they mostly just don't use salt?

Salt handling is certainly one of the least well documented and messiest
areas in kerberos, with many odd behaviors in different servers and
libraries.  I suspect very few people actually have the patience
to go through and trace all the variations of salt usage out.

					-Marcus Watts

---

From: Sam Hartman <[email-masked]>
Date: Thu, 22 Jun 2006 08:33:45 -0400

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> "Shawn M. Emery" <[email-masked]> writes:
    >>> Notable differences include support for AES which is mandated
    >>> by RFC 4120, but which will not be hugely common until Windows
    >>> Vista ships.  MIT, Heimdal, Solaris and Apple have had AES for
    >>> a hile now, though.
    >>> 
    >>  There are a number of implementations that don't enforce
    >> requirements made by RFC 4120.  For example:
    >> 
    >> Implementations of Kerberos and protocols based on Kerberos
    >> MUST NOT use insecure DNS queries to canonicalize the hostname
    >> components of the service principal names (i.e., they MUST NOT
    >> use insecure DNS queries to map one name to another to
    >> determine the host part of the principal name with which one is
    >> to communicate).

    Simon> There are several other examples:

    Simon> 1) Nobody else's implementation that I've tested seem to
    Simon> behave according to RFC 4120 wrt to the high bit set on TCP
    Simon> connections.

Really?
MIt certainly intended to behave correctly.
Do you have a simple test case?  If you could describe the problem within the next day or so, we could probably get a fix into 1.5.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 22 Jun 2006 15:25:03 +0200

> Do you have a simple test case?  If you could describe the problem within the next day or so, we could probably get a fix into 1.5.

The details were posted in:

http://article.gmane.org/gmane.ietf.krb-wg/4342

I confirmed this again with Debian's krb5-kdc version 1.4.3-7.

To test this, just send a message with all bits set:

jas@latte:~$ printf "\xff\xff\xff\xff" | nc localhost 88

The KDC closes the connection and logs:

Jun 22 15:19:01 localhost krb5kdc[5081]: TCP client 127.0.0.1.44841 wants 4294967295 bytes, cap is 1048572

It would be useful to have one implementation that behaves according
to RFC 4120 to test with, when Shishi tries to use the extension
mechanism against a server that doesn't support it.

/Simon

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 22 Jun 2006 12:59:44 -0400

> 4294967295 bytes, cap is 1048572

The bit that's noncompliant here is that you're supposed to first send a 
KRB-ERROR message with KRB_ERR_FIELD_TOOLONG.