Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-kerb-00.txt

From: [email-masked]
Date: Thu, 09 Nov 2000 06:21:07 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security Working Group of the IETF.

	Title		: Kerberos Cipher Suites in Transport Layer Security (TLS)
	Author(s)	: M. Hur, A. Medvinsky
	Filename	: draft-ietf-tls-kerb-00.txt
	Pages		: 
	Date		: 08-Nov-00
	
RFC 2712 [KERBTLS] introduced mechanisms for supporting Kerberos 
[KERB] authentication within the TLS protocol [TLS].  This document 
extends RFC 2712 to support delegation of Kerberos credentials.  In 
this way, a TLS server may obtain a Kerberos service ticket on behalf 
of the TLS client.  Thus, a single client identity may be used for 
authentication within a multi-tier architecture.  This draft also 
proposes a mechanism for a TLS server to indicate Kerberos-specific 
information to the client within the certificate request message in 
the initial exchange.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tls-kerb-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-tls-kerb-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-tls-kerb-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: David Hopwood <[email-masked]>
Date: Fri, 10 Nov 2000 08:49:39 +0000

-----BEGIN PGP SIGNED MESSAGE-----

>         Filename        : draft-ietf-tls-kerb-00.txt

This references the KRB5 ciphersuites from RFC 2712, and adds three
more:

   CipherSuite     TLS_KRB5_WITH_DES_CBC_SHA            = { 0x00,0x1E };
   CipherSuite     TLS_KRB5_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x1F };
   CipherSuite     TLS_KRB5_WITH_RC4_128_SHA            = { 0x00,0x20 };
   CipherSuite     TLS_KRB5_WITH_IDEA_CBC_SHA           = { 0x00,0x21 };
   CipherSuite     TLS_KRB5_WITH_DES_CBC_MD5            = { 0x00,0x22 };
   CipherSuite     TLS_KRB5_WITH_3DES_EDE_CBC_MD5       = { 0x00,0x23 };
   CipherSuite     TLS_KRB5_WITH_RC4_128_MD5            = { 0x00,0x24 };
   CipherSuite     TLS_KRB5_WITH_IDEA_CBC_MD5           = { 0x00,0x25 };

   CipherSuite     TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA  = { 0x00,0x26 };
   CipherSuite     TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA  = { 0x00,0x27 };
   CipherSuite     TLS_KRB5_EXPORT_WITH_RC4_40_SHA      = { 0x00,0x28 };
   CipherSuite     TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5  = { 0x00,0x29 };
   CipherSuite     TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5  = { 0x00,0x2A };
   CipherSuite     TLS_KRB5_EXPORT_WITH_RC4_40_MD5      = { 0x00,0x2B };

   CipherSuite     TLS_KRB5_WITH_NULL_SHA               = { 0x00,0x?? };
   CipherSuite     TLS_KRB5_WITH_NULL_MD5               = { 0x00,0x?? };
   CipherSuite     TLS_KRB5_WITH_NULL_NULL              = { 0x00,0x?? };

TLS_KRB5_WITH_NULL_NULL is a really bad idea, and I cannot see any
legitimate use for it. Note that *no* existing ciphersuites that can be
negotiated have a NULL MAC, so adding such a ciphersuite is a significant
protocol change that can only weaken security. (There is also little
point in adding TLS_KRB5_WITH_NULL_MD5.)

Something similar to the following note from RFC 2712 should be put in
the text of the new draft, and extended to the 56-bit single DES
ciphersuites (TLS_KRB5_WITH_DES_CBC_{SHA,MD5}).

# IESG Note:
#
#    The 40-bit ciphersuites defined in this memo are included only for
#    the purpose of documenting the fact that those ciphersuite codes have
#    already been assigned.  40-bit ciphersuites were designed to comply
#    with US-centric, and now obsolete, export restrictions.  They were
#    never secure, and nowadays are inadequate even for casual
#    applications.  Implementation and use of the 40-bit ciphersuites
#    defined in this document, and elsewhere, is strongly discouraged.

IMHO the draft should say that the 40- and 56-bit ciphersuites SHOULD
NOT be used.

Another reason to deprecate { 0x00,0x1E } (TLS_KRB5_WITH_DES_CBC_SHA),
is that this code is also assigned by [FKK96], for
SSL_FORTEZZA_KEA_WITH_RC4_128_SHA.

The draft should also say that the KRB5 ciphersuites do not provide
forward secrecy, and are vulnerable to off-line dictionary attacks [Wu99].

There's a technical change needed to the CertificateRequest message that
the draft does not make clear:

  struct {
      ClientCertificateType certificate_types<1..2^8-1>;
      /* KeyExchangeAlgorithm is determined by ServerHello.ciphersuite */
      select (KeyExchangeAlgorithm) {
          case krb5:
             KerbInfo kerberos_info;
          default:
             DistinguishedName certificate_authorities<3..2^16-1>;
      }
  } CertificateRequest;

Also, the kerberos client certificate type MUST NOT be included in
certificate_types for non-Kerberos ciphersuites, and other certificate
types MUST NOT be included for Kerberos ciphersuites (this is needed to
make the interpretation of CertificateRequest unambiguous).

[FKK96] Alan O. Freier, Philip Karlton, Paul C. Kocher,
        "The SSL Protocol Version 3.0,"
        Internet draft (work in progress, expired March 1997).
        draft-freier-ssl-version3-02.txt
        http://home.netscape.com/eng/ssl3/draft302.txt

[Wu99]  Thomas Wu,
        "A real world analysis of Kerberos password security,"
        In Proceedings of the 1999 Internet Society Network and
        Distributed System Security Symposium.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

---

From: David Hopwood <[email-masked]>
Date: Fri, 10 Nov 2000 08:49:39 +0000

-----BEGIN PGP SIGNED MESSAGE-----

# IESG Note:
#

  struct {

[Wu99]  Thomas Wu,

- -- 

---

---

From: Eric Rescorla <[email-masked]>
Date: 10 Nov 2000 07:26:42 -0800

David Hopwood <[email-masked]> writes:
> legitimate use for it.
I agree. I suspect this is just a search and replace error.

-Ekr

---

---

From: Matthew Hur <[email-masked]>
Date: Fri, 10 Nov 2000 11:02:04 -0800

Thanks for the comments.  Responses are below.

--Matt

>point in adding TLS_KRB5_WITH_NULL_MD5.)

As Eric stated in his email, TLS_KRB5_WITH_NULL_NULL was a search and 
replace error.  I will remove it.

>#    defined in this document, and elsewhere, is strongly discouraged.

That note has already been included in the draft (see appendix B).

>IMHO the draft should say that the 40- and 56-bit ciphersuites SHOULD

I'll add a note in the security considerations section.

>SSL_FORTEZZA_KEA_WITH_RC4_128_SHA.

You are referring to an internet draft that expired in March 1997?

>forward secrecy, and are vulnerable to off-line dictionary attacks [Wu99].

See the security considerations section.

>make the interpretation of CertificateRequest unambiguous).

OK

>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.3i
>Charset: noconv
>
>iQEVAwUBOgu2jDkCAxeYt5gVAQFOrwf/UVbWO+wliVKHSglYalz/dOBcKM65D8T2
>sKaDwxMO5g51iow5mkWj9G9eZ7pYBHIjndAcpUPbRHp/An1fDgrnkqqdbdeidJDO
>rkCJws3AjRoeUfNeuqTSK6QeHbNP4LIop/8UfzDxAd3Z1DmDvMc3V/Cp4dFfHRur
>6UWu/ro/irr3PMvC6R7cdtKK7dl6kzYHmwZh0A4oH9ba3fZPAdX0utRh6nC72Y2R
>molB6RGSM0CDXEKqVO0DrUFYFXRJZjf2cVGrUqZR31odXP8rP9tcdSfAvdxBcm9Q
>I5Ure4MDhkyvl3wGuSNooYBrEgPm6K699QFF0muA7SKv4f31q2V8eA==
>=bZN0
>-----END PGP SIGNATURE-----
>
>
>---
>You are currently subscribed to ietf-tls as: [email-masked]
>To unsubscribe send a blank email to 
>[email-masked]

---

---

From: Eric Rescorla <[email-masked]>
Date: 10 Nov 2000 11:13:27 -0800

> You are referring to an internet draft that expired in March 1997?
True, but these cipher suites are in deployment, at least inside
NSA. Since we've got enough cipher suite numbers to play
around with...

-Ekr

---

---

From: Matthew Hur <[email-masked]>
Date: Fri, 10 Nov 2000 12:24:17 -0800

OK - I'll blank out that ciphersuite, and we can re-assign a number to it 
if no one objects.

--Matt

---

---

From: [email-masked] (Nelson Bolyard)
Date: Fri, 10 Nov 2000 15:41:12 -0800

> You are referring to an internet draft that expired in March 1997?

Well, yes, it is an expired draft.  It's also essentially THE spec for SSL3
as implemented in all Netscape browsers, and presumably most other browsers
and clients that implement SSL3.  All Netscape 4.x browsers implement and
recognize (00,1E) as SSL_FORTEZZA_KEA_WITH_RC4_128_SHA.  I'd rather avoid 
having the value (00,1E) have different meaning in SSL3 than in TLS.

BTW, while we're on this topic, would anyone object to the draft [FKK96]
being submitted as a "historic" or "informational" RFC (not standards track)
for the purpose of finally having a real IETF RFC that documents the 
existing practice of SSL3?

--
Nelson Bolyard               Sun / Netscape Alliance
Disclaimer:                  I speak for myself, not for Netscape

---

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 10 Nov 2000 18:46:09 EST

> existing practice of SSL3?

I am attempting to argue in favor of something similar in the SSH
community.  I highly encourage that this be done BUT only with the
following qualification:

  someone must write the pre-amble to this document that explains
  why it should not be used.  

otherwise, it is pointless to publish it as people will continue to
implement SSL3 intead of TLS in their applications.

                  Jeffrey Altman * Sr.Software Designer
                 The Kermit Project * Columbia University
               612 West 115th St * New York, NY * 10025 * USA
     http://www.kermit-project.org/ * [email-masked]

---

---

From: David Hopwood <[email-masked]>
Date: Sat, 11 Nov 2000 06:25:27 +0000

-----BEGIN PGP SIGNED MESSAGE-----

Matthew Hur wrote:
> David Hopwood wrote:

It's the current specification of SSL 3.0, and is described as such on
Netscape's site. All that the new draft really needs to do is note the
conflict.

In another article:
> OK - I'll blank out that ciphersuite, and we can re-assign a number
> to it if no one objects.

Why bother, given that it's single DES?

> See the security considerations section.

Ah, for some reason I missed that. The first sentence of that section
should probably be

# Kerberos ciphersuites are subject to the security considerations of
# both the TLS protocol, and the Kerberos 5 protocol [KERB]. 

>       /* KeyExchangeAlgorithm is determined by ServerHello.ciphersuite */
                                      should be cipher_suite ^^^^^^^^^^^
>              DistinguishedName certificate_authorities<3..2^16-1>;

I don't have any further comments.

- -- 

---