Subject: Re: Kerberos V5 over TLS and draft-josefsson-krb-tcp-expansion.txt

From: Simon Josefsson <[email-masked]>
Date: Tue, 02 May 2006 15:21:56 +0200

What is the next step to make this move forward?

Thanks,
Simon

Simon Josefsson <[email-masked]> writes:

> I've updated the extension draft:
>
> http://www.ietf.org/internet-drafts/draft-josefsson-krb-tcp-expansion-02.txt
>
> It has these changes:
>
> * It now uses a bitmask to indicate extensions.
>
> * It won't drop the TCP connection if the server doesn't support an
>   extension, instead it let the client know what is supported and let
>   the client re-try.
>
> * I've changed the IANA considerations to require IESG Approval since
>   I dislike expert review (and nobody volunteered to write acceptable
>   expert review guidelines), and apparently the first come first serve
>   approach was not acceptable.
>
> * I've fixed the copying conditions.
>
> I believe this is ready to go, but given the major changes, I welcome
> more review to make sure we have consensus on this new approach.
>
> Thanks,
> Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 2 May 2006 08:58:34 -0500

> What is the next step to make this move forward?

I think you ask Sam for publication.  Which should lead to an IETF last
call, IESG vote, and so on.

Er, two comments:

 - do reserve one bit (i.e., just 30 extension bits)

 - the server SHOULD NOT (not MUST NOT) close the connection...  Why?
   Because there's always resource availability issues to consider.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 02 May 2006 13:58:53 -0400

> call, IESG vote, and so on.

... and Sam says no, like last time.

This needs to be done within the working group; it can't be done as an 
individual submission.  Since there seems to be active discussion on this 
document, and there are at least two open issues I'm aware of, I don't 
think it is ready for WGLC.

One of the open issues is how existing implementations might behave when 
presented with this extension, and in particular whether there are any 
which are broken in ways that make this a bad idea.  Simon has said a 
couple of times "I'm not really worried about this", but that's not good 
enough.  At least one person has indicated that they are worried, and so 
far I've not actually seen any evidence that the problem doesn't exist, 
only "we can check".  Someone needs to _actually_ check, and report back on 
what they find.

The other is the question of what the allocation policy should be for 
extension bits.  That's not something the document author gets to decide 
unilaterally; there needs to be a WG consensus on this question.

At present, this item is not listed as a work item of this working group. 
Since there is clearly interest in working on it, active WG members have 
commented, and I haven't seen any comments saying we _shouldn't_ work on 
it, I think we have consensus to add the item.  After a discussion with 
Sam, I also believe it's within our charter, though it's something of a 
corner case(*).  So, I'm going to ask the secretariat to list this as a WG 
item.

Simon, you're welcome to submit the next version with a draft-ietf-krb-wg-* 
filename, or continue using the existing name.  If you decide to switch 
names, you need to CC me on the submission of the -00 file, since I will be 
asked to approve the change.

-- Jeff

(*) Sometime in the not-too-distant future, we need to have a discussion 
about rechartering with a more specific set of work items.  I'll try to 
start that discussion on the mailing list in time to give it some 
face-to-face meeting time in Montreal.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 02 May 2006 22:06:11 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> individual submission.  Since there seems to be active discussion on
> this document, and there are at least two open issues I'm aware of, I
> don't think it is ready for WGLC.

Ok.

> One of the open issues is how existing implementations might behave
> when presented with this extension, and in particular whether there
> are any which are broken in ways that make this a bad idea.  Simon has
> said a couple of times "I'm not really worried about this", but that's
> not good enough.  At least one person has indicated that they are
> worried, and so far I've not actually seen any evidence that the
> problem doesn't exist, only "we can check".  Someone needs to
> _actually_ check, and report back on what they find.

Oh, I'm sorry you got that impression.  I agree it is a concern, and
that it should be investigated.  I thought that anyone who was worried
about this could check it themselves, since it only takes a few
minutes.  I did check it, and the section "Interoperability
Consideration" was added to -02 as a result.  It contains the short
version of the results.  I recall discussing that section on the list.
I didn't get the message that it was not adequate.  The section reads:

4.  Interoperability Consideration

   Implementations with support for TCP that do not claim to conform to
   RFC 4120 may not handle the high bit correctly.  Behaviour may
   include closing the TCP connection without any response, and logging
   an error message in the KDC log.  When this was written, this problem
   existed in modern versions of popular implementations.
   Implementations experiencing trouble getting the expected responses
   from a server SHOULD assume that it does not support this extension
   mechanism.  Clients MAY remember this semi-permanently, to avoid
   excessive logging in the server.  Care should be taken to avoid
   unexpected behaviour for the user when the KDC is eventually
   upgraded.  How to handle these backwards compatibility quirks are in
   general left unspecified.

If you are looking for more details, below is my attempt to explain
how at least two implementations behave.

First, remember that none of these implementations conform to RFC 4120
here.  If we are extending RFC 4120, it seems appropriate to assume
RFC 4120 conformance.

MIT Kerberos:

Andrew Bartlett quoted krb5 sources before, in:

http://article.gmane.org/gmane.ietf.krb-wg/4070/match=message+big

and I've confirmed that it behaves as the code says.  I.e., when I
configure Shishi to talk TLS to a MIT Kerberos KDC, the KDC will log
something like this in the log for PROBEs:

May  2 21:32:09 localhost krb5kdc[6323]: TCP client 127.0.0.1.47384 wants 2147483648 bytes, cap is 1048572

Assuming the TLS extension will be allocated the first bit, invoking
the TLS extension directly results in a log entry as follows:

May  2 21:35:20 localhost krb5kdc[6323]: TCP client 127.0.0.1.39053 wants 2147483649 bytes, cap is 1048572

The KDC closes the TCP connection, and the stream does not seem to
linger on, so it appears to have shutdown the socket correctly too.
This is consistent with my reading of the code as well.

For reference, the MIT KRB5 code is:

                conn->u.tcp.msglen = ((p[0] << 24)
                                      | (p[1] << 16)
                                      | (p[2] <<  8)
                                      | p[3]);
                if (conn->u.tcp.msglen > conn->u.tcp.bufsiz - 4) {
                    /* 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;

This suggests any message with the high bit set will get the same
treatment.

Heimdal:

The code is in kdc/connect.c:handle_tcp():

    n = recvfrom(d[index].s, buf, sizeof(buf), 0, NULL, NULL);
...
    memcpy(d[index].buf + d[index].len, buf, n);
    d[index].len += n;
    if(d[index].len > 4 && d[index].buf[0] == 0) {
        ret = handle_vanilla_tcp (&d[index]);
    } else if(enable_http &&
              d[index].len >= 4 &&
              strncmp((char *)d[index].buf, "GET ", 4) == 0 &&
              strncmp((char *)d[index].buf + d[index].len - 4,
                      "\r\n\r\n", 4) == 0) {
        ret = handle_http_tcp (&d[index]);
        if (ret < 0)
            clear_descr (d + index);
    } else if (d[index].len > 4) {
        kdc_log (0, "TCP data of strange type from %s", d[index].addr_string);
        return;
    }

None of the if-cases are taken (d[index].len is 4), so the function
will return, which leads to the KDC to wait for 4 seconds to receive
more data that could trigger one of the if-cases.  The timeout is hard
coded in the file.

Eventually, after 4 seconds, the KDC will log:

2006-05-02T21:45:15 TCP-connection from IPv4:192.168.1.3 expired after 4 bytes

It closes and shut down the socket correctly.  The code suggests any
message with the high bit set will get the same treatment.

> extension bits.  That's not something the document author gets to
> decide unilaterally; there needs to be a WG consensus on this
> question.

I've changed the policy after the last discussions, and there has been
no new comments.  The new policy is:

   IANA needs to create a new registry for "Kerberos 5 TCP Extensions".
   The initial contents of this registry should be:

   [[RFC Editor: Replace xxxx below with the number of this RFC.]]

   Bit #         Meaning                             Reference
   -----         -------                             ---------
   0..29         AVAILABLE for registration.
   30            RESERVED.                           RFC XXXX

   IANA will register values 0 to 29 after IESG Approval, as defined in
   BCP 64 [2].  Assigning value 30 requires a Standards Action.

> At present, this item is not listed as a work item of this working
> group. Since there is clearly interest in working on it, active WG
> members have commented, and I haven't seen any comments saying we
> _shouldn't_ work on it, I think we have consensus to add the item.
> After a discussion with Sam, I also believe it's within our charter,
> though it's something of a corner case(*).  So, I'm going to ask the
> secretariat to list this as a WG item.
>
> filename, or continue using the existing name.  If you decide to
> switch names, you need to CC me on the submission of the -00 file,
> since I will be asked to approve the change.

Thanks!  I'll wait for any comments on the new version though.

Regards,
Simon

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 02 May 2006 16:55:46 -0400

> how at least two implementations behave.

Speaking as an individual, I'm reasonably satisfied that the behavior for 
MIT and heimdal is acceptable.  If I were actually to deploy a client which 
supported TCP extensions, I'd want to be able to disable them on a 
realm-by-realm basis through local configuration, to avoid the 4 second 
delay on realms which are known not to support them.

I'd love to see someone describe how the Microsoft KDC behaves.

> here.  If we are extending RFC 4120, it seems appropriate to assume

I think the practical reality is that KDC's which attempt to support TCP 
transport as described in RFC4120 are already fairly widely deployed, and 
we should make some effort to ensure reasonable behavior even with those 
which do not handle the high-bit-set case well.  As I said above, the 
behavior you describe for MIT and Heimdal seems acceptable to me.

>    [[RFC Editor: Replace xxxx below with the number of this RFC.]]

Speaking again as chair, I'd like to see some comments on this.  Anyone?

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 03 May 2006 12:08:51 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> Speaking as an individual, I'm reasonably satisfied that the behavior
> for MIT and heimdal is acceptable.  If I were actually to deploy a
> client which supported TCP extensions, I'd want to be able to disable
> them on a realm-by-realm basis through local configuration, to avoid
> the 4 second delay on realms which are known not to support them.

Right.  I've added:

    Implementations MAY also provide a way to enable and disable this
    extension on a per-realm basis.

FWIW, Shishi has to be explicitly configured to even try the extension
at all.

> I'd love to see someone describe how the Microsoft KDC behaves.

Me too.

> Speaking again as chair, I'd like to see some comments on this.  Anyone?

I'd like to see more comments as well.  Given the heated discussions,
I gave up on my pushing my own (first-come-first-serve) ideas here,
and will modify the IANA section to suit whatever comments are
received, if you judge the consensus.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 03 May 2006 14:48:52 +0200

> Er, two comments:

Thanks!

>  - do reserve one bit (i.e., just 30 extension bits)

One is reserved:

Bit #         Meaning                             Reference
-----         -------                             ---------

>    Because there's always resource availability issues to consider.

Agreed.  Resource availability consideration should be spelt out
explicitly too.  I've changed MUST to SHOULD and added:

      <t>Resource avaibility considerations may influence whether, and
	for how long, the KDC will wait for the client to send
	requests.</t>

Regards,
Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 May 2006 09:13:25 -0500

> received, if you judge the consensus.

I like the current text.  30-31 bits are very few, so that assignment on
a first-come-first-serve basis would be dangerous.

Now, maybe the extension mechanism should be more complex so that
first-come-first-serve assignments can be practical, but I don't see a
need for this -- we'll not have more than a handful of these extensions,
if that many (I can picture two extensions, including the TLS
extension).

So I am in favor of the current text.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 May 2006 09:33:18 -0500

On Wed, May 03, 2006 at 04:20:08PM +0200, Simon Josefsson wrote:
> > first-come-first-serve assignments can be practical, but I don't see
> > a need for this
> 
> We can use the RESERVED bit to build another extension mechanism if a
> need develops.

Yes, but even so, if IANA liberally assigned the first 30 to some joker
then the rest of the IETF KRB community would then be forced to pursue
Standards Action to remediate the problem.  I think IESG Approval is a
fine requirement.

> > (I can picture two extensions, including the TLS extension).
> 
> You've piqued my curiosity. :)

:)

I haven't thought it through, and perhaps no TCP extension is needed for
it, but, IPsec + connection latching + channel binding.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 03 May 2006 16:20:08 +0200

Thanks!

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 03 May 2006 23:04:05 +0200

Nicolas Williams <[email-masked]> writes:

> Standards Action to remediate the problem.

The IANA is permitted to reject clearly bogus registrations.  Maybe we
could have 15 of the 30 to be assigned on a first-come-first-serve
basis, so I later can prove my point...  I don't think anyone will
request a bit without sufficient justification to warrant reserving a
bit.  If someone feel they need a bit, especially when we can only
imagine use of at most two bits today, I feel they can have the bit.

Oops, now I'm starting to debate the policy again.  I'll be silent now
and let others decide this...

Thanks,
Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 May 2006 16:06:09 -0500

> and let others decide this...

Alright, let's put this to bed then: is there any reason to think that
requiring IESG approval would suck?  For you?  For anyone else?

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 03 May 2006 17:48:17 -0400

> and let others decide this...

No, debate is good.  It's only unilateral decisions that are bad.

This space is fairly scarce; there are only 30 possible extensions and 
there is already a proposal to use up over 3% of that space (that is, one 
bit).  I think that's plenty of justification for requiring that bits be 
allocated through the IETF, and not on a first-come-first-served basis.

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 04 May 2006 10:36:20 +0200

> requiring IESG approval would suck?  For you?  For anyone else?

Not really.  However, I don't see a good reason why
first-come-first-serve would suck either, and in that case my personal
preference is to use first-come-first-serve.  The IANA can reject
bogus registrations, which would take care of the problem with jokers
who allocate them all.

Has there been any documented examples of when the
first-come-first-serve policy for protocol extension fields like this
one that has actually caused harm?

It seems others don't share my personal preference on this, and even
if I don't see the justification for it, I'm fine with IESG Approval.

/Simon

---

From: Andrew Bartlett <[email-masked]>
Date: Mon, 08 May 2006 20:41:35 +1000

> only "we can check".  Someone needs to _actually_ check, and report back on 

BTW, has there been any consideration to an alternative to the 4-byte
prefix discovery mechanism?  Why should the extension be squeezed into
such a small space?

I was wondering if a kerberos packet asking for the use of an extension
might be more 'in band', and cause a direct, detectable error (hopefully
a KRB-ERROR packet) on more implementations?  I really think that an
extension certainly shouldn't require timeout/close detection for widely
deployed servers.

I'm suppose I'm thinking of something like how START-TLS is done in
LDAP.

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: Wed, 10 May 2006 17:20:26 +0200

Andrew Bartlett <[email-masked]> writes:

> prefix discovery mechanism?

The general "in-band" extension mechanism is, I believe, PA-DATA
fields.

> Why should the extension be squeezed into such a small space?

Do we need more?  This extension mechanism is only for TCP-specific
extensions.  General Kerberos extensions should not use this
mechanism.

Btw, since there have been few comments lately, I'll submit an updated
version with the (minor) changes that I incorporated as a result of
the discussions.

Thanks,
Simon

---

From: Andrew Bartlett <[email-masked]>
Date: Thu, 11 May 2006 01:50:47 +1000

> The general "in-band" extension mechanism is, I believe, PA-DATA

That sounds like a fine place to shove this.  

> extensions.  General Kerberos extensions should not use this

To me it's a fine point, and one that rubs up poorly against existing
networks.  But I'm not from around here :-)

If a larger space were used, there would be less need for allocation of
bits/integers, as extensions could be described by text/OID/large-number
etc.  

Andrew Bartlett

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 10 May 2006 11:13:22 -0500

> That sounds like a fine place to shove this.  

I don't agree.  The problem is that you'd need to have some sort of
AS-REQ even if that's only for the purpose of negotiating this sort of
extension in-band.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 18 May 2006 12:14:50 +0200

> AS-REQ even if that's only for the purpose of negotiating this sort of

I also believe PA-DATA isn't the right extension mechanism to
negotiate things like TLS -- one of the reasons for using TLS is to
avoid leaking the information in the AS-REQ.  I realize we could use a
degenerative AS-REQ here, with empty or dummy values, but to me that
seems to be a poor solution to use in a standard.

Are there more issues, or are we ready for WGLC?  Jeff?  I realize
that not many have read the updated document, so there may be large
problems, but a WGLC would get the ball in motion again, and would
allow me to work on addressing the issues, instead of waiting for
people to accidentally read the draft.

/Simon

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 18 May 2006 09:21:11 -0400

> seems to be a poor solution to use in a standard.

I agree.  It may be that in rfc1510ter, we want to add some sort of control 
message for negotiation in situations where we need to know if a particular 
extension is supported before it is appropriate to send a KDC-REQ or 
AP-REQ.  I certainly would rather see that than a proliferation of "dummy" 
request messages used for this purpose.

> people to accidentally read the draft.

<chair hat on>
I know of no more issues, and it looks like the current ones have died down 
with people mostly being satisfied with what the current document says. 
Sadly, your observation about a WGLC getting more people to actually read 
the document is pretty much on the mark, so we may as well go ahead and do 
that.  Let me know if you have an updated document you want to submit 
before we start WGLC, or if I can go ahead with the -00 version you 
submitted last week.

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 18 May 2006 15:42:27 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> I know of no more issues, and it looks like the current ones have died
> down with people mostly being satisfied with what the current document
> says. Sadly, your observation about a WGLC getting more people to
> actually read the document is pretty much on the mark, so we may as
> well go ahead and do that.  Let me know if you have an updated
> document you want to submit before we start WGLC, or if I can go ahead
> with the -00 version you submitted last week.

I haven't made any edits to the document, so -00 is the latest.

For reference, some background material is available from
<http://josefsson.org/krb5starttls/>.

Note that the TLS document has not been updated for the latest
iteration of the extension document.  Since the extension protocol has
been changed, I'm going to wait until we are fairly confident that
there will be no more modifications to it, until I update my
implementation and the TLS document.  I'm not confident of that now,
and it is kind of blocking my progress, since I don't want to
implement something that is likely to change again.  After the WGLC,
I'll have more indication on whether the current protocol is going
forward or not, at least.

Thanks,
Simon