Subject: STARTTLS document

From: Simon Josefsson <[email-masked]>
Date: Tue, 08 Nov 2005 01:08:26 +0100

Hi all.  We briefly touched on my STARTTLS option for Kerberos 5 at
the meeting today.  It was suggested to post this link to the list
too, so here goes:

http://josefsson.org/krb5starttls/

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 15 Nov 2005 09:24:37 +0100

Hi all.  I extracted the TCP/IP expansion mechanism from my
KRB5STARTTLS draft, and published it below.

Let me know if there is any interest in moving this forward,
regardless of the merits of KRB5STARTTLS.

Thanks,
Simon

> 	Title		: Kerberos 5 TCP/IP Expansion Mechanism
> 	Filename	: draft-josefsson-krb-tcp-expansion-00.txt
> 	Pages		: 7
> 	Date		: 2005-11-14
> 	
>    An expansion mechanism for the Kerberos 5 TCP/IP Transport is
>    described.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-josefsson-krb-tcp-expansion-00.txt

---

From: Andrew Bartlett <[email-masked]>
Date: Tue, 15 Nov 2005 20:02:38 +1100

> regardless of the merits of KRB5STARTTLS.

My worry about the TCP/IP expansion mechanism is: do widely deployed
implementations conflict with the extension?

That is, I can't find this in Heimdal, and I know I missed it in Samba4
(fortunately I can fix that before release), but I wonder what other
implementations correctly implement the error response this detection
relies on?

(Would a new type of kerberos packet get a more universal negative error
response, to detect incompatible servers?)

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 15 Nov 2005 10:47:07 +0100

> implementations conflict with the extension?

I don't know.  I assume implementations follow the RFC.  If an
implementation doesn't, that is arguable a bug that should be fixed
anyway.

> implementations correctly implement the error response this detection

Finding out would be useful.

> response, to detect incompatible servers?)

Perhaps.  A new pre-auth-token, as Sam suggested, may be one way to
go.  I did not experiment with this because there were no interest
from the WG earlier.  I disagree that the pre-auth solution is nicer
because of the reason of symmetry between TLS and DTLS negotiations --
I believe you would need a separate pre-auth-token for DTLS anyway.
DTLS and TLS are not the same protocol, so they would have to be
negotiated separately.

Thanks,
Simon

---

From: Andrew Bartlett <[email-masked]>
Date: Tue, 15 Nov 2005 21:17:04 +1100

> implementation doesn't, that is arguable a bug that should be fixed

Perhaps it's just because I've spent too long with CIFS, but it seems
like a big assumption to me.

> Finding out would be useful.

krb5-current has:
                   /* message too big */
                    krb5_klog_syslog(LOG_ERR, "TCP client %s wants %lu
bytes, cap is %lu",
                                     conn->u.tcp.addrbuf, (unsigned
long) conn->u.tcp.msglen,
                                     (unsigned long) conn->u.tcp.bufsiz
- 4);
                    /* XXX Should return an error.  */
                    goto kill_tcp_connection;

Heimdal doesn't seem to handle it, but I don't have Microsoft's source
code :-).  I could test, but I think my point is made...

> DTLS and TLS are not the same protocol, so they would have to be

This much is over my head, sorry :-)

Andrew Bartlett

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 15 Nov 2005 11:42:34 +0100

> code :-).  I could test, but I think my point is made...

Yes, it seems that you are right.

At the very least, my draft need to state that some implementations do
not follow RFC 4120, and that you should treat any unexpected
behaviour as indicating lack of support of the expansion mechanism.

I'm not yet convinced this kill my proposal, though, since we could
simply treat the above behavior as bugs in existing implementations.

My proposal is to either update RFC 4120 to say the highest bit cannot
be used at all, or we consider an expansion mechanism similar to what
I have proposed.  If we can't use this expansion mechanism, we won't
be able to use any other either, as far as I can tell.

Thanks,
Simon