Subject: Meeting at IETF65

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 17 Jan 2006 18:05:43 -0500

It's that time again.  The deadline for requesting meeting slots for IETF65 
is February 13, and before then I'd like to have some idea of what will be 
on our agenda and how much time we'll need.

We've sent PKINIT and enctype negotiation to the IESG; the latter is 
currently in IETF-wide last call.

The WGLC on PKINIT-ECC expired yesterday; there were a couple of comments 
to which I have not yet seen responses.

Our next milestones involve addressing issues for anonymous (March) and 
getting major issues resolved on extensions (June).  So, these are the 
issues I'd like to see us spend meeting time on.

So for starters, I'll propose an agenda something like this:

Preliminaries - Jeffrey Hutzelman (5 min)
  - Introduction
  - Blue Sheets
  - Scribe, Jabber
  - Agenda Bashing

Document Status - Jeffrey Hutzelman (5 min)
  - pkinit, pkinit-ecc, enctype-nego, extensions, anonymous

Technical Discussion (90 min)
  - anonymous
  - extensions

Update Milestones - Chair and Participants (10 min)

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 18 Jan 2006 10:29:44 +0100

Jeffrey Hutzelman <[email-masked]> writes:

> Our next milestones involve addressing issues for anonymous (March)

Is there any interest in adopting my STARTTLS solution for this?

The idea builds on the TCP expansion mechanism documented in:

http://josefsson.org/krb5starttls/draft-josefsson-krb-tcp-expansion.txt

The separate STARTTLS document has not been updated to reference the
previous document, so there is some duplication in the following
document, but at least it describe the protocol:

http://josefsson.org/krb5starttls/draft-josefsson-kerberos5-starttls.txt

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 18 Jan 2006 14:47:59 +0100

Andrew Bartlett <[email-masked]> writes:

> On Wed, 2006-01-18 at 10:29 +0100, Simon Josefsson wrote:
> Didn't we determine that widely deployed servers didn't respond in a way
> conducive to this method of expansion?  

Yes, but it is not clear to me what that means for this idea.  Those
implementations are violating RFC 4120, so that could be considered a
bug.  This may warrant an implementation notice in the above document
that clients may treat other server error modes as indication that the
server doesn't support the extension, but that doesn't seriously harm
the idea as far as I can see.  Servers will need to be upgraded to
support TLS in any case, and at least my Kerberos clients generally do
not query random KDCs.

If we can't utilize this extension bit in RFC 4120, I believe we'd
better document that fact and close the extension hole.

> Could an alternative be a different message, rather than playing with
> the 'length'?

A new pre-auth token may be another solution.  I'm not sure how well
existing implementations handle unknown pre-auth tokens though.

> This is far more likely to provoke a response (negative in some way)
> compared with hanging hopes for 4G of incoming data.

Was that really what happened?  I still think it could be dealt with
through an implementation notice, to handle the transition period when
the old servers are upgraded.  The client could close the connection
if it doesn't receive any response after some time, which the server
should notice and close the connection.

In our implementation, we need Kerberos 5 over TLS (for anonymity,
downgrade attacks, server authentication and OpenPGP client
authentication and possibly more), so I'd welcome more discussion on
how to proceed.  If the expansion mechanism in RFC 4120 is unusable,
let's document that and find another solution.

Thanks,
Simon

---

From: Andrew Bartlett <[email-masked]>
Date: Thu, 19 Jan 2006 00:32:27 +1100

Could an alternative be a different message, rather than playing with
the 'length'?  This is far more likely to provoke a response (negative
in some way) compared with hanging hopes for 4G of incoming data.

Andrew Bartlett

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