Subject: referrals and enctypes

From: Ken Raeburn <[email-masked]>
Date: Fri, 25 Apr 2003 16:22:30 -0400

This came up while Sam, Tom and I were working out how to deal with
the fact that our GSS code won't support AES session keys.  It's not
an immediate problem for us, but we should keep it in mind for future
work.

If my client's GSS implementation, supporting 3DES, RC4 and DES, wants
to talk to an FTP server at ftp.example.com, currently it gets a TGT
for EXAMPLE.COM (assuming that's the determined realm name), and asks
the EXAMPLE.COM KDC for a 3DES, RC4 or DES ticket for the FTP server.
The fix we're working on at the moment is, in part, to not limit the
requested TGT to the short list of enctypes as well; there's no reason
not to use AES for the TGT.

Under the referral model, I'd contact my local KDC, asking for a 3DES,
RC4, or DES ticket for ftp/ftp.example.com, and I'd get back the
ticket I requested, or a TGT.  But if I get back a TGT, it's also
going to be limited to that same enctype list, needlessly.

The KDC is supposed to obey the enctype list provided.  Perhaps, in
the case where we return a TGT instead, we could consider extending
the list with other enctypes the client implementation is known to
support, but barring additional configuration information on the KDC,
all we know it supports are the session key and subkey types.  And we
don't know where they should fit in the preference order relative to
the requested enctypes.

And if there aren't any types in common -- perhaps my TGT session key
is of some new experimental type CWC-AES-32, the cross-realm TGT info
only indicates AES256-CTS-HMAC-SHA1-96 support, the client GSS code
supports only 3DES, RC4, and DES, and the client krb5 code supports
all five -- it may still be possible to do the authentication if only
we could get the correct information -- a second enctype list -- to
the KDC.

Yes, we're going to try to fix GSS, but the same problem applies to
any application that wants to limit the session key to a particular
set of types.

On a related note, if the client knew what sort of enctypes the server
GSS implementation supported for use in the GSS mechanism, a key of a
suitable type could be negotiated using the subkey fields, and the
session key could be any type both krb5 implementations support.  But
since we don't provide that information, we have to rely on the
session key type as our only hint....

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 25 Apr 2003 13:52:39 -0700

Obviously, fixing this will require some extensions work.  We need to
distinguish between a client's requested enctypes for intermediate TGTs
and a client's requested enctypes for the final ticket (usually a
service ticket) that was actually requested by the client application.

The one KDC-REQ enctypes field today works fine enough, until referrals
are thrown it.  Looks like KDC-REQ-X needs two enctypes fields (but, see
below).

Of course, this would NOT be a problem if rfc1964 did not require
updates for new Kerberos V enctypes - and it shouldn't be a problem
after rfc1964 gets revised and every one upgrades (ha!).

Ken's suggestion of enctype negotiation in the AP exchange is
interesting.  Again, it wouldn't be needed but for applications that
have specific enctype knowledge hardcoded (e.g., telnet, rfc1964).  But
since it is we might consider a sub-key enctype negotiation extension in
the extensions work.  If we assume that people who should know better
will, in the future, design application-level protocols that hardcode
knowledge of specific enctypes, then such an extension would be
worthwhile.  Any such AP exchange extension should be designed such that
it plays well with any PFS extensions (particularly if the PFS
extensions are done via typed-holes).

Either of these two approaches will do in the extensions future, I think.

Cheers,

Nico
--

---

From: Derek Atkins <[email-masked]>
Date: 26 Apr 2003 00:18:54 -0400

Question: can't you assume that the enctype of the TGT is an
"assumed to be ok" version?  For example, if a client presents
an AES TGT, can't you assume the client supports AES?

In a similar vein, can't you record the inital enctypes list
inside the TGT?  You clearly know what the client supports
when they perform the AS_REQ, no?

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Ken Raeburn <[email-masked]>
Date: Sat, 26 Apr 2003 15:48:29 -0400

> an AES TGT, can't you assume the client supports AES?

Go back and look at the example I mentioned, where the original TGT
has a new or locally-defined type not supported by the cross-realm
TGS.  Then adding in that enctype doesn't help you.

> when they perform the AS_REQ, no?

Perhaps.  I wonder, though, if there are cases where you might want to
limit the specified enctypes in the AS-REQ message.  Remember that in
the AS-REQ case, we also have at least two key enctypes we might want
to control -- the client's long-term key, any keys generated through a
preauth mechanism which might use the client's long-term key as an
input, and the session key.

It wouldn't help when acquiring forwarded or proxy tickets to send to
another system with a potentially different implementation though.  Or
if we want to support using two implementations on one system.

>> interesting.

It wasn't so much of a suggestion as as observation, but....

If we did allow the client to propose an enctype set in the AP-REQ
message, and allow the server to specify the key to be used by both
sides in the AP-REP, or perhaps a single enctype from the client's
list and the second half of the PFS negotiation, we could probably
avoid application-specific restrictions on the session key type.  But
that's only for applications using the updated protocol and an AP-REP
message.

>>   If we assume that people who should know better
>> worthwhile.

I think it's safe to say there will be applications that want to use
the key for their own purposes instead of generating AP-REQ and
KRB-PRIV messages, or even the crypto framework operations.  So
they'll need to know how to handle different key types.  And I think
it would be foolish of us to claim that we know better than they.

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 28 Apr 2003 07:51:18 -0700

> an AES TGT, can't you assume the client supports AES?

Yes, I think we could do that.  But that's a single enctype we can add
to the list of requested enctypes for referrals - the referral had
better be possible with one of those enctypes.

E.g., if the client had a TGT with an AES session key and requested
{DES, 3DES} and the KDC had to issue a referral which could only be
issued with RC4, then the referral can't be issued, even if the client
did support RC4.

> when they perform the AS_REQ, no?

Yes, I think this would be ok, but it's still an extension.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 28 Apr 2003 07:59:13 -0700

> that's only for applications using the updated protocol and an AP-REP

Yup, 'twould not work for non-mutual auth.

> it would be foolish of us to claim that we know better than they.

Couldn't the crypto framework specify a way to get a session-key derived
bit string for use as key material outside the context of Kerberos
crypto?  That way any such apps could be decoupled from the Kerberos
concept of a key enctype.  Just because the app does it's own session
crypto doesn't mean that it should limit its Kerberos requested enctypes
or that it should be limited by Kerberos ticket session key enctypes.

> if we want to support using two implementations on one system.

Good points.  We need two requested enctypes lists in the KDC-REQ so
that one can be used for non-TGT replies and one can be used for TGT
replies.

Cheers,

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: Mon, 28 Apr 2003 13:25:25 -0400

Nicolas Williams <[email-masked]> writes:
> crypto?

You mean like the PRF function added at the last minute?

>   That way any such apps could be decoupled from the Kerberos

True, but that won't get rid of existing protocols.

> that one can be used for non-TGT replies and one can be used for TGT

Where does the long-term key fit into this?  Say I have an AES key for
daemon/foo-server, and I want to get an initial ticket for
ftp/ftp.example.com.  I support AES, RC4, 3DES and DES, but my GSS
implementation only supports 3DES and DES.  Should I list AES only,
for the long-term key?  Should I list 3DES and DES, for the service
ticket I want?  Should I list AES, RC4, 3DES and DES, for an
intermediate TGT?

If we add an extra list, I think it's pretty clear it should be
optional, and default to the value of the first list, since in most
applications they won't need to be distinct.

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 28 Apr 2003 11:06:51 -0700

> You mean like the PRF function added at the last minute?

:)

> True, but that won't get rid of existing protocols.

Fixed rfc1964 + SSH w/ GSS-API keyex + 5+ years will, provided no new
bad protocols come up.

> ticket I want?  Should I list AES, RC4, 3DES and DES, for an

Why should the pre-auth enctype always be strongly related to the ticket
enctypes?

> applications they won't need to be distinct.

Yes.

Nico
--