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

From: Simon Josefsson <[email-masked]>
Date: Wed, 05 Apr 2006 01:28:06 +0200

We are going to deploy Kerberos V5 over TLS, and I'd like to
standardize the mechanism used within the IETF.  Can I ask the chair
to ask the WG whether it wishes to adopt the following document that
would enable us to achieve that goal?

http://www.ietf.org/internet-drafts/draft-josefsson-krb-tcp-expansion-00.txt

Alternatively, to suggest an approach that would be acceptable for
standardization within the WG.

The background is that because of the little interest in my approach,
I concluded that the WG was not interested in this work.  So I asked
the IESG to publish my approach as an individual standard.  The
response was that it must be standardized by this WG.  I understand
that the WG may have other priorities, but since this is our main
priority standardization wise, and I'd like to move forward, I feel
compelled to ask again.

This work is currently divided into two parts.  The
draft-josefsson-krb-tcp-expansion.txt document doesn't deal with TLS
at all, it is a simple expansion mechanism for Kerberos V5 over TCP.

Andrew has pointed out that some implementations doesn't follow RFC
4120, but I believe that can be handled by an implementation note,
much like the many things in RFC 4120 itself about buggy
implementations.  I can survey in more detail exactly how MIT Kerberos
and Heimdal behave, if that would clarify the situation.  The second
document would simply request IANA to allocate one of the available
expansion slots for Kerberos V5 over TLS.

Thanks,
Simon

Simon Josefsson <[email-masked]> writes:

> 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: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 4 Apr 2006 19:55:47 -0400 (EDT)

On Wed, 5 Apr 2006, Simon Josefsson wrote:

> response was that it must be standardized by this WG.

As they should have.  At points in the past where you've brought this up,
it seemed to me there was interest in discussing it, but not enough to
make people drop what they were doing to work on it.  That's fine -- one
of the problems we have is that too much of the active work is being done
by the same small set of people, which means it gets done very slowly.

I was hoping to discuss this work at our meeting in Dallas, but you didn't
seem to be around, so I saw little point in doing so at that time.  That
doesn't mean we can't discuss it here.

> I understand

Don't just ask, _do_! :-)

Seriously, the best thing you can do to make the work happen is to drive
it.  Getting and responding to feedback and updating the documents, which
you're clearly doing here, is pretty much the way to make things happen.

> at all, it is a simple expansion mechanism for Kerberos V5 over TCP.

Because this needs to use the reserved bit, it pretty much has to be done
in the IETF.  I consider this work to be within the scope of our charter,
and I haven't heard anyone screaming that developing an extensibility
mechanism along these lines is a bad idea.  To make this officially a
working group item, we need to come up with a timeline and milestones we
can get our Area Director to agree to.

[technical discussion deleted]

> The second

I think this document is in scope as well, to the extent that it's a
proposal for how to protect the AS exchange.  Exactly what direction we
take with this will be up to the WG.

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

I'm not sure why there weren't any responses to this, except that maybe no
one thought your document had any relation to anonymous tickets.  I'm
sorry if you were mislead into thinking there was no interest in pursuing
this work.

Next steps for this...

- estimate when the TCP-extension document might be ready for WGLC.
- resolve the broken-implementations question
- resolve the question of negotiating extensions and figuring out
  what your peer supports without having to establish and close down
  multiple TCP connections
- what other open issues do you know about?

If there are people who are interested in helping with this work, or who
object to taking it on as a work item, please speak up.

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 05 Apr 2006 02:35:22 +0200

> by the same small set of people, which means it gets done very slowly.

Understood.

> doesn't mean we can't discuss it here.

Excellent!  I wasn't in Dallas, hopefully I can make it to some future
meeting and possibly explain this further.

> you're clearly doing here, is pretty much the way to make things happen.

Right.  I have added an Interopability Consideration to the document,
and will re-submit it.

> can get our Area Director to agree to.

I believe the document is ready.  Giving people time to review it
until right before (or after?) the next meeting seem fair.  July 06
then?

> take with this will be up to the WG.

I also think that part can wait.  It is not as critical as the
expansion mechanism.  If my current TLS expansion is flawed, it is
simple to allocate another expansion hole for it, for the solution
that the WG decides on.

> - estimate when the TCP-extension document might be ready for WGLC.

I believe this version

is ready now.  Of course, it will have to be submitted first.

The only difference between the last IETF version is that it add a
section called "Interopability Consideration".

> - resolve the broken-implementations question

Andrew looked at MIT Kerberos, I can test Heimdal.  I believe the
document above already address this sufficiently, though.

>   what your peer supports without having to establish and close down

I'm not sure I follow.  Do you think a server that doesn't understand
a particular expansion should not close the stream (which the document
says now), but rather send some other token to signal that it didn't
understand the particular expansion, and wait for the client to try
again?  That may be a good idea actually.

> - what other open issues do you know about?

I can't recall anything else.

Thanks,
Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 4 Apr 2006 20:32:54 -0500

> meeting and possibly explain this further.

No need to wait that long.  Your draft is fairly small and
self-explanatory.  More importantly, it leaves room for other
extensions.  It's basically close.  Drive some discussion, request a
WGLC and it should get through easily enough.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 04 Apr 2006 23:27:49 -0400

> until right before (or after?) the next meeting seem fair.  July 06

Well, when we believe there are no outstanding issues and the document is 
in shape to be published, we can do a 2-week working group last call. 
Since the majority of IETF work is done on the mailing lists rather than in 
face-to-face meetings, it's not necessary to wait for a meeting to move 
something forward.

However, I can't last-call a document until it is formally a WG work item, 
and I won't when there are known outstanding issues.

> simple to allocate another expansion hole for it, for the solution

I haven't read the latest version of your tcp-expansion document yet.  What 
assignment policy are you proposing for the extension numbers?

> document above already address this sufficiently, though.

Unfortunately, what you or I alone believe is not all that matters.  This 
particular issue relates to whether your approach is feasible at all, and 
so it needs to be addressed before we can proceed.  More specifically, we 
need to know how bad the problem is, and the WG needs to form a consensus 
as to whether to continue in this direction.

> again?  That may be a good idea actually.

Well, it's already established that a server which doesn't recognize that 
bit at all has to close the connection.  But assuming a client and server 
both support your extensibility mechanism, I would rather see a 
well-defined negotiation mechanism up front than find out a few years from 
now that clients are having to open several TCP connections to a KDC before 
they find a combination of extensions that the KDC supports...

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 5 Apr 2006 01:34:59 -0500

Comments on the I-D:

The document title should probably not mention "IP."  I suggest
"Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges
Over TCP."

The behaviour required by RFC4120 is repeated in more than one place in
this I-D:

 - referenced in the introduction
 - copied in the introduction
 - restated in the first paragraph of section 3
 - partly restated in the third paragraph of section 3

I think that's too much redundancy.  Strike Section 3, paragraphs 1 and 3.

>   This document describe how the high bit is used to implement an
>   expansion mechanism.  This expansion mechanism is intended for
>   features that are specific for the TCP/IP transport.

s/describe/describes/

s,/IP,,

>   Kerberos 5 require Key Distribution Centers ...

s/require/requires/

But then, I'd strike that paragraph entirely (see above).

>   We will use the reserved bit to provide an expansion mechanism.  When
>   the reserved high bit is set, the remaining 31 bits of the 4 octets
>   are treated as an extensible typed hole, and thus form a 31 bit
>   integer enumerating various expansions.  Each of the values indicate
>   a specific extended operation mode, which are to be described
>   elsewhere.

If those four octets encode, when the high bit is set, an integer, then:

s/extensible typed hole/extension identifier/

But do we want an integer?  Or a bitmask?

If a bitmask then one bit should be reserved for extending the bitmask,
leaving a 30-bit bitmask.

I think an integer is fine, but it limits the protocol to one extension
at a time.  A bit mask would not, but, how would the selected extensions
inter-play?

>   If the KDC do not understand ...

s/do not/does not/

>   The following table specify the meaning of the 31 lower bits in the 4
>   octet field, when the high bit is set:

s/specify/specifies/

>   Because the initial length field is not protected, it is possible for
>   an active attacker (i.e., one that is able to modify traffic between
>   the client and the KDC) to make it appear to the client that the
>   server do not support this expansion.  Client and KDC policies can be
>   used to reject connections that do not use any expansion.

s/do not/does not/

Is there any reason not to require expert review for IANA registration
of these extensions?  And note that section 3, last paragraph implies
open extension specifications ("Each expansion mechanism MUST
describe..."), while the IANA Considerations section is moot on the
matter -- please pick a policy, be consistent about it and document it
in the IANA Considerations section.

Section 6 is a bit out of the ordinary for an I-D...  I think it may not
conflict with BCP78, but IANAL, so...

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 05 Apr 2006 10:22:41 +0200

> Comments on the I-D:

Thanks for reviewing it!

> "Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges

Changed, although I changed 'Extended' to 'Expanded', to avoid
confusing this work with the other 'extension' work going on.  If
'extended' reads better, I can change it.

> I think that's too much redundancy.  Strike Section 3, paragraphs 1 and 3.

Agreed.

Paragraph 3 of section 3 was not about the RFC 4120 behaviour, though,
it was about how to handle unsupported expansions within this
mechanism.  But I can see how it was read the wrong way, especially
after the excessive redundancy.  That section will probably be
re-worked as per Jeffrey's ideas though.

> s/do not/does not/

Done.

> s/extensible typed hole/extension identifier/

Fixed.

> at a time.  A bit mask would not, but, how would the selected extensions

The problem of interacting extensions lead me to use an integer.

Perhaps the solution here is to reserve the upper 15 bits (below the
fixed high bit) for future bitmask ideas.  The lower 2^16 bits,
interpreted as an integer, could server as the expansion slot, and
should be sufficient.  And if it isn't sufficient, defining an
expansion-expansion mechanism using the reserved upper 15 bits is
possible.

> of these extensions?

Is there a reason to require it?

My experience is that additional burdens to get a number from IANA
slow down the process, and make people assign numbers to themselves,
causing interop troubles later on.  With 2^31 available integers, or
even with 2^16, I don't think there will be sufficiently many requests
to the IANA, that aren't non-sense requests, to warrant creating more
bureaucracy.

Writing good expert reviewer guidelines is also rather challenging.

> And note that section 3, last paragraph implies open extension
> specifications ("Each expansion mechanism MUST describe..."), while
> the IANA Considerations section is moot on the matter -- please pick
> a policy, be consistent about it and document it in the IANA
> Considerations section.

The MUST was intended to refer to implementations, not specifications.

> conflict with BCP78, but IANAL, so...

Similar text has been approved before, so I don't anticipate any
problems.  The reason for it is that I wish to make it possible to
include the document in free software; the current IETF copying
conditions are too restrictive to permit that.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 05 Apr 2006 10:28:21 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> Well, when we believe there are no outstanding issues and the document
> is in shape to be published, we can do a 2-week working group last
> call. Since the majority of IETF work is done on the mailing lists
> rather than in face-to-face meetings, it's not necessary to wait for a
> meeting to move something forward.
>
> However, I can't last-call a document until it is formally a WG work
> item, and I won't when there are known outstanding issues.

Ok.  I'll try to resolve all the issues and publish a new revision.

> I haven't read the latest version of your tcp-expansion document yet.
> What assignment policy are you proposing for the extension numbers?

   Decimal         Meaning                             Reference
   -------         -------                             ---------
   0               RESERVED.                           RFC XXXX
   1...2147483647  AVAILABLE for registration.
   2147483648      RESERVED.                           RFC XXXX

   IANA will register new values on a First Come First Served basis, as
   defined in BCP 64 [2].  Changing the RESERVED values (0 and
   2147483648) will require IETF Consensus.

   While the registration procedures do not require expert review,
   authors of expansion are encouraged to seek community review and
   comment whenever that is feasible.  Authors may seek community review
   by posting a specification of their proposed mechanism as an
   Internet-Draft.  Expansions intended for widespread use should be
   standardized through the normal IETF process, when appropriate.

> Unfortunately, what you or I alone believe is not all that matters.
> This particular issue relates to whether your approach is feasible at
> all, and so it needs to be addressed before we can proceed.  More
> specifically, we need to know how bad the problem is, and the WG needs
> to form a consensus as to whether to continue in this direction.

I will do what I can do to help that.

The situation with MIT Kerberos doesn't seem alarming to me, the KDC
will close the TCP connection and log an error.  The new interop
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 expansion
   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.

> Well, it's already established that a server which doesn't recognize
> that bit at all has to close the connection.  But assuming a client
> and server both support your extensibility mechanism, I would rather
> see a well-defined negotiation mechanism up front than find out a few
> years from now that clients are having to open several TCP connections
> to a KDC before they find a combination of extensions that the KDC
> supports...

That is a good point.  I will work on this.  I think the server should
respond with some 4-octet token with the high bit set, and the client
can parse this, and possibly send further expansion tokens until some
expansion is selected, or the client shut down the connection.

Thanks,
Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 5 Apr 2006 08:19:54 -0500

> The problem of interacting extensions lead me to use an integer.

That's what I figured...

> Is there a reason to require it?

The "[e]ach expansion mechanism MUST describe..." sentence made me think
that you were not being consistent on this, so that's really my main
question here.

> to the IANA, that aren't non-sense requests, to warrant creating more

Aren't you pursuing a separate IETF document describing how to do TLS in
the KDC exchanges over TCP?  If so then I think that getting IESG
approval counts as having had expert review (in this case because both
security ADs are experts in this subject matter).  You should not get
slowed down here at all.

> Writing good expert reviewer guidelines is also rather challenging.

Then why not just require IETF protocol action?

We can always relax these requirements later when we've gained
experience with the protocol.

> The MUST was intended to refer to implementations, not specifications.

You can see how I did not read it that way...

> conditions are too restrictive to permit that.

What?  The IETF license is not at all so restrictive.  You might want to
talk to a lawyer...

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 05 Apr 2006 09:46:29 -0400

>    Decimal         Meaning                             Reference

I disagree with this approach.  Any extension to Kerberos should require
the publication of an RFC.  It can be an Experimental RFC instead of
standards track but it must be published.   If we don't require at least
publication then we are going to end up in the same mess that Telnet
Options did.  IANA would issue option numbers, someone would implement
some functionality without documenting it, and suddenly one day you have
dozens of deployed products each with non-interoperable implementations.
You also end up with vendors who choose to do private things.

If you wish you can break up the allocation space to provide a small
number, say a range of 16 values, that can be used for private testing.
However, it should be stated that these values are not to be used in
production environments.

Jeffrey Altman

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 05 Apr 2006 10:02:36 -0400

[speaking as an individual participant, not as chair...]

I'm looking at draft-josefsson-krb-tcp-expansion-00.txt, which is the 
version currently in the I-D repository.  So, I've not seen any 
modifications which may have been made in the as-yet-unpublished -01.

> "Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges

Agree.
:%s#TCP/IP#TCP#g

Also, for consistency with our other documents, please use the words 
"extensibility" and "extension" rather than "expansion" (but it is not 
necessary to change the draft filename which is, after all, just a 
filename).

The abstract could be a bit wordier...

  This document describes an extensibility mechanism for the
  Kerberos v5 protocol when used over TCP transports.

> I think that's too much redundancy.  Strike Section 3, paragraphs 1 and 3.

So do I.  In fact, I don't think it's even necessary to quote RFC4120, as 
you are referencing it normatively.  I'd drop all but the first paragraph 
of the introduction.

However, I would _not_ drop the third paragraph of section 3, which 
describes the behavior when a KDC _does_ understand TCP extensibility but 
does not understand the particular extension requested by the client.  This 
case is (obviously) not covered in RFC4120.

> s/describe/describes/

This document repeatedly makes this particular error.  If Simon can manage 
to stop doing so (which may not be easy), great.  If not, let's leave it 
for the copy editors.

>>   a specific extended operation mode, which are to be described

If we're going to strike the first paragraph of section 3 as Nico suggests, 
then we might need to say something better than just "the reserved bit". 
For example...

  The reserved high-order bit of the request length field is used to
  provide an extension mechanism.  When this bit is set...

> at a time.  A bit mask would not, but, how would the selected extensions

It doesn't have to limit the protocol to one extension at a time; you just 
have to allow more than one extension word.  If we're going to use 
integers, I would suggest that each extension word be followed by a length 
and whatever data is required for that extension, after which there can be 
another extension or a normal Kerberos message, or perhaps a flag 
indicating there is no normal Kerberos message (we could reserve extension 
0 for that purpose).

Whether you're using integers or an extensible bitfield, the problems with 
combining extensions do not seem to be any worse than in the rest of the 
protocol.

I do think it is important for the server to be able to read the request 
and indicate whether it supported the requested extensions, and if not, 
which ones it did not support.  It should then be possible to process 
another request without closing the channel.  With the current model, 
you're looking at a minimum of two round trips (SYN, SYN/ACK, ACK/request, 
response/FIN) for each extension the client tries which is not supported by 
the server.

There is also the question of whether unsupported extensions are critical. 
If the server does not recognize an extension, should it process the 
message anyway, or return a KRB-ERROR?  If the latter, then it would seem 
obvious to specify the use of typed-data for that error and define a 
TD-type indicating which extensions were unsupported, or perhaps which 
extensions _are_ supported.

While this would not be particularly consistent with the rest of Kerberos, 
it might be desirable to be able to query the server to find out what 
extensions it supports.  Perhaps an extension should be defined for this, 
and designated as REQUIRED for servers which support the TCP extension 
mechanism.

> in the IANA Considerations section.

rfc1510ter does not yet contain text specifying the assignment policy for 
positive extension numbers in the rest of Kerberos.  However, RFC4120 does 
define policies to be used in the event we conclude without producing 
rfc1510ter and IANA needs to take over the existing registries.  In every 
case, there is a least a requirement for expert review.

In this particular case, I think expert review is a good idea, as it allows 
the expert to intercept people who are trying to use this mechanism when 
they should be using a transport-independent extensibility mechanism.

The other question is, if we publish this document now, should we create 
this one table now, or wait until we do the others?

> conflict with BCP78, but IANAL, so...

At a minimum, this section should make it clear whether it is intended to 
apply to the I-D itself or to the resulting RFC.  In either case, there are 
potential issues.  It's not clear whether it permits rendering in other 
formats, and and the last sentence as written would appear to prevent the 
creation of derivative works as part of the IETF standards process.

Simon, I understand what you're trying to do, but text like the last 
sentence of section 6 can be problematic if not carefully written.  I don't 
want this WG to fall into a legal rathole; it's not our area of expertise. 
If you want to keep something along these lines, I will consult the IPR WG 
and try to find out what problems they think might arise.

In any event, if this section remains, it should be moved closer to the end 
of the document, perhaps adjacent to the Copyright Statement, and should 
not be numbered.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 05 Apr 2006 10:11:01 -0400

> What?  The IETF license is not at all so restrictive.  You might want to

The IETF does not (and cannot) grant the right to create derivative works 
of IETF documents outside the IETF standards process.  Because the 
copyrights on our documents are retained by the author(s) with only 
specific rights granted to the IETF, only the author(s) have the power to 
grant this right.

This does not prevent IETF documents from being shipped alongside free 
software (even GPL'd software), but it does make the documents themselves 
non-free, according to some people's definition.  In particular, Debian has 
a strong policy of only shipping things that are "free", and IETF documents 
do not fall within their definition.

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 05 Apr 2006 16:28:56 +0200

> that you were not being consistent on this, so that's really my main

Point taken.  Of course, the policy should be clear and consistent.
It seems Jeffrey argues for a different policy, so this may change.

> security ADs are experts in this subject matter).  You should not get

Getting an RFC reviewed and published typically takes at least a year,
so I disagree.  If it is this difficult to get a value from IANA, I
believe people will pick a value and run with it.  I think this is
more harmful than handing out numbers for flawed protocols.

> experience with the protocol.

Jeffrey's suggestion of having a "experimental" range may solve this
too.

> What?  The IETF license is not at all so restrictive.  You might want to

I've talked to lawyers, and we've had pro-bono lawyers (from the FSF)
concur with our interpretation.  I've brought this up with the IPR WG
too, and I haven't heard anyone say that our interpretation is
incorrect.  The IPR WG has re-chartered to fix this problem, so it
seems others agree that this is a problem.  For example, Debian does
not accept material derived from RFCs in their software because they
consider the IETF license non-free.

I recommend you to read RFC 3978 carefully, especially the license in
3.3.  The license their does not give you, as a third party, any
rights whatsoever.  Oops.

However, this is getting off topic...  Maybe move it to the IPR WG if
we want to continue.

Thanks,
Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 5 Apr 2006 09:50:58 -0500

> 3.3.  The license their does not give you, as a third party, any

I should have been more clear.  The first sentence of section 6 is not
at all a problem, but the second may be, and the third clearly needs
some wordsmithing (the IETF should retain the right to re-format, not
just translate, and to update and obsolete this document while also
copying parts of it -- I doubt you intend to prevent this).

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 5 Apr 2006 09:55:02 -0500

> Jeffrey's suggestion of having a "experimental" range may solve this

Registration by RFC, BTW, doesn't necessarily mean that you can't deploy
implementations until the RFC issues (historically anyways).

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 05 Apr 2006 16:59:41 +0200

> modifications which may have been made in the as-yet-unpublished -01.

Thanks for your comments.  -01 will contain the result of this
discussion.

>> "Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges

I've changed this, although I note that RFC 4120 use TCP/IP in several
places.

> necessary to change the draft filename which is, after all, just a

Since both you and Nico suggested this, I've changed this now.  I
initially thought the title might be confused with other Kerberos
extensions.

>  Kerberos v5 protocol when used over TCP transports.

Changed.

> So do I.  In fact, I don't think it's even necessary to quote RFC4120,
> as you are referencing it normatively.  I'd drop all but the first
> paragraph of the introduction.

I've changed the section somewhat, but I kept the quote.  I don't
think it hurts, and makes it more self-contained.

> describes the behavior when a KDC _does_ understand TCP extensibility
> but does not understand the particular extension requested by the
> client.  This case is (obviously) not covered in RFC4120.

Agreed.

>> s/describe/describes/
>
> This document repeatedly makes this particular error.  If Simon can
> manage to stop doing so (which may not be easy), great.  If not, let's
> leave it for the copy editors.

Yes, I need a grammar checker..  I appreciate getting them fixed.

> If we're going to strike the first paragraph of section 3 as Nico
> suggests, then we might need to say something better than just "the
> reserved bit". For example...
>

Good, added.

> It doesn't have to limit the protocol to one extension at a time; you
> just have to allow more than one extension word.  If we're going to
> use integers, I would suggest that each extension word be followed by
> a length and whatever data is required for that extension, after which
> there can be another extension or a normal Kerberos message, or
> perhaps a flag indicating there is no normal Kerberos message (we
> could reserve extension 0 for that purpose).

Hmmm, interesting approach.  I agree that it doesn't have to limit the
protocol.

> Whether you're using integers or an extensible bitfield, the problems
> with combining extensions do not seem to be any worse than in the rest
> of the protocol.
>
>
> I do think it is important for the server to be able to read the
> request and indicate whether it supported the requested extensions,
> and if not, which ones it did not support.  It should then be possible
> to process another request without closing the channel.  With the
> current model, you're looking at a minimum of two round trips (SYN,
> SYN/ACK, ACK/request, response/FIN) for each extension the client
> tries which is not supported by the server.

Yes, this is bad.

> There is also the question of whether unsupported extensions are
> critical. If the server does not recognize an extension, should it
> process the message anyway, or return a KRB-ERROR?  If the latter,
> then it would seem obvious to specify the use of typed-data for that
> error and define a TD-type indicating which extensions were
> unsupported, or perhaps which extensions _are_ supported.
>
> While this would not be particularly consistent with the rest of
> Kerberos, it might be desirable to be able to query the server to find
> out what extensions it supports.  Perhaps an extension should be
> defined for this, and designated as REQUIRED for servers which support
> the TCP extension mechanism.

This approach seem more efficient than probing for various extensions.

> rfc1510ter does not yet contain text specifying the assignment policy
> for positive extension numbers in the rest of Kerberos.  However,
> RFC4120 does define policies to be used in the event we conclude
> without producing rfc1510ter and IANA needs to take over the existing
> registries.  In every case, there is a least a requirement for expert
> review.
>
> In this particular case, I think expert review is a good idea, as it
> allows the expert to intercept people who are trying to use this
> mechanism when they should be using a transport-independent
> extensibility mechanism.
>
> The other question is, if we publish this document now, should we
> create this one table now, or wait until we do the others?

I'd be interested to hear further discussion on this.  I do have
opinion on this, but it is not critical.

> At a minimum, this section should make it clear whether it is intended
> to apply to the I-D itself or to the resulting RFC.  In either case,
> there are potential issues.  It's not clear whether it permits
> rendering in other formats, and and the last sentence as written would
> appear to prevent the creation of derivative works as part of the IETF
> standards process.

That wasn't the intention, the IETF policy still apply, of course.

> sentence of section 6 can be problematic if not carefully written.  I
> don't want this WG to fall into a legal rathole; it's not our area of
> expertise. If you want to keep something along these lines, I will
> consult the IPR WG and try to find out what problems they think might
> arise.

I'd like to keep this section, because otherwise others can't use my
document as part of their documentation, and it probably can't be
included in Debian.  The IESG has approved my RFC 4027 and RFC 4398
with similar text, derived from RFC 3492, and I recall that the sha-2
document contained additional copying conditions that also required
users to reference the document.  Having the IPR WG review the text
may be useful.

> In any event, if this section remains, it should be moved closer to
> the end of the document, perhaps adjacent to the Copyright Statement,
> and should not be numbered.

I've moved it to an appendix, I'm not sure how to make ut non-numbered
with xml2rfc.  If it is important, I could have some sed script do
post-processing.

Thanks,
Simon

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 05 Apr 2006 11:11:03 -0400

> implementations until the RFC issues (historically anyways).

True, but you may not be able to do so until it reaches the point in the 
RFC-Editor process at which the IANA assigns values.

In any case, neither "expert review" nor "specification requires" has to 
mean a published RFC, and I think Jeff Altman is being overly conservative 
due to his bad experiences with telnet, where there were a wide varity of 
implementations which suppored various options based on different versions 
of internet-drafts.  That is an argument for not implementing against 
I-D's, but not an argument for requiring that every extension be published 
_as an RFC_.

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 05 Apr 2006 17:12:39 +0200

> You also end up with vendors who choose to do private things.

Requiring published RFCs slow down deployment and will most likely
lead to vendors picking a number before IANA has assigned one, to be
able to test their implementations.  That goes against the idea of
standardizing running code.

The text already say that expansions that are likely to be used widely
(e.g., with multiple implementations) should be standardized through
the normal IETF process.  Compared to the telnet situation, anything
that is intended to be used outside company-internal networks should
be standardized.  I would agree that the language could be
strengthened a lot here.

> However, it should be stated that these values are not to be used in

Perhaps a further compromise would be to have one range be allocated
on a first-come-first-served basis, and one range for IETF "standard"
extensions.

I'd like to hear more opinions on this.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 05 Apr 2006 17:24:02 +0200

> copying parts of it -- I doubt you intend to prevent this).

Oh, right.  The -00 document is rather old, and used my then-current
copying conditions.  Since then I have reverted to the RFC 3492
language:

   Regarding this entire document or any portion of it, the author
   makes no guarantees and is not responsible for any damage resulting
   from its use.  The author grants irrevocable permission to anyone
   to use, modify, and distribute it in any way that does not diminish
   the rights of anyone else to use, modify, and distribute it,
   provided that redistributed derivative works do not contain
   misleading author or version information.  Derivative works need
   not be licensed under similar terms.

This will be part of -01.

Thanks,
Simon

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 05 Apr 2006 13:10:18 -0400

Jeffrey Hutzelman wrote:

> mean a published RFC, and I think Jeff Altman is being overly
> conservative due to his bad experiences with telnet, where there were a
> wide varity of implementations which suppored various options based on
> different versions of internet-drafts.  That is an argument for not
> implementing against I-D's, but not an argument for requiring that every
> extension be published _as an RFC_.
> 
> -- Jeff

The situation with Telnet is that IANA issued option numbers without
requiring that there was appropriate documentation.  This resulted in
options being allocated for all sorts of features many of which were
conflicting and some of which it was never known what they were being
used for.  In one instance, the person to whom the option number was
allocated decided to re-use the option number for something else even
though there was already deployed code.

I believe that similar problems occurred within the DHCP space with
regards to the use of the local use range.

I believe that extensions to IETF protocols must receive review by IETF
experts and be documented by the publication of RFCs.  I understand that
people are well intentioned but unless you inform people on what they
should do then inevitably there are going to be some who don't.

Jeffrey Altman

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 05 Apr 2006 14:05:54 -0400

> though there was already deployed code.

Yes, and that was bad.  Howver, since that time, we have a new IANA and new 
sets of procedures.  The allocation policy is no longer "Jon thinks it will 
work out in the end",  The solution to the problem you describe is not to 
require publication of the spec for every extension as an RFC.

> regards to the use of the local use range.

No, what happened there was that vendors who couldn't get coordinated DHCP 
option numbers chose to deploy their vendor-specific options by usurping 
the local-use space, which was designated for coordinated use _within a 
site_, instead of using encapsulated vendor options, which is a mechanism 
that has been in place since well before DHCP was widely deployed.

> experts and be documented by the publication of RFCs.

I'm going to assume you mean you believe the IETF should require extensions 
to its protocols to meet these conditions, and not that such requirements 
are actually in place.  Given that assumption, I think that is far too 
strong a blanket requirement.  It is very close to saying that IETF 
protocols should only ever be extended in the IETF, and that's not 
reasonable or realistic.  It's also not necessary.

The problems you saw with telnet were not due to an overly liberal option 
number assignment policy.  They were due to people implementing different 
verisons of specs under development, or attempting to implement incomplete 
specs, or, in at least one case, someone reusing an option number that had 
already been assigned.  A different allocation policy would not have fixed 
this.

People who ask for number assignments are doing so to _avoid_ conflicts, 
not to cause them.  They may not always want to publish specifications. 
There is no reason that there can't be extensions for which the 
specifications are not public.  Of course, not everyone will be able to 
implement such specifications, but sometimes, that's OK.

I don't see a technical reason why it is necessary to have a stronger 
requirement than expert review for this extension mechanism or (nearly) any 
of the others we've defined.  Even requiring IETF action for AD types seems 
extreme to me.

> I understand that

That's why you require expert review.  Then the expert can intercept people 
who are going down the wrong path and point them in the right direction. 
Of course, some people will do the wrong thing anyway, but there's nothing 
you can do about those, and requiring a public specification before you 
register an option number certainly isn't going to help.

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 25 Apr 2006 11:38:18 +0200

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