Subject: Re: Reading list for extensions discussion

From: Sam Hartman <[email-masked]>
Date: Wed, 10 Sep 2003 18:34:49 -0400

Hi.  Here are the proposals we made in December of 2001.  All this is
old content from the mailing list archives, reposted for your
enjoyment.

Of particular note, many open issues are still open.

While discussing section 5 of the Kerberos revisions document in
London, Tom presented an outline of a strategy to handle extensibility
by using ASN.1 constraints and ASN.1 choices.  We believed that this
strategy would add enough extensibility features to deal with parts of
the protocol that were made optional in revisions, adding ticket
extensions, providing the framework we need for UTF8 and solving
backward compatibility problems while avoiding the unnecessary
complexity and protocol changes that concerned the working group with
the proposal made in Minneapolis.  The working group seemed generally
receptive to this approach and Tom indicated he would move forward.

Since then, Tom Yu, Ken Raeburn, Jeff Hutzelman, Jeffrey Altman and I have been working to flesh out this proposal and
confirm that it met our needs.   

Over the next few days we are presenting our findings to the working
group.  This message presents a more detailed explanation of why  we
need to address extensibility in Kerberos than was presented in
London.  Future messages will explain why we believe that  we need to
think about all the extensibility issues together rather  than
handling each of them separately.  We will then present the details of
our proposal including  exactly how clients can discover if a KDC or
service has  support for new protocol features in a backward
compatible way.  We do have a specific proposal ready, but we want to
make sure that people understand the motivation before presenting
ASN.1.

			  Why Extensibility?

One of the primary arguments for building extensibility into Kerberos
is to meet changing market requirements.  In the past we have seen
that companies cannot wait for the standards process to provide the
features they need.  Companies can choose which existing standards
they use, and how they fit their needs into those standards, but in
general waiting to ship a product on changing a standard creates
unacceptably long delays. If Microsoft had waited on the
standardization of the kdc-issued authorization data element, Windows
2000 would still be delayed.

We certainly want companies to be able to use our standards.  However
we want them to use our standards in such a way that products from one
company will interoperate with products from other companies.  In some
cases we can make our standards general enough or tailored to a
specific need so that products will not have to extend them.  For
example, most
companies implementing IP do not find the need to extend the protocol;
it solves the very general problem of getting packets from one point
to another.  For other IETF standards, we suspect that vendors will
want to extend the standard.  HTTP has been popular in part because
vendors were able to test out extensions like caching, byte-ranges
and vendor-specific additions in a compatible way without waiting for
the standards process.

Parts of Kerberos are like IP.  I can't see that many ways a vendor
would want to extend the krb-priv message; if they want to send
different data they can just  put something different in the user data
field.  Other parts of Kerberos seem more like HTTP: many proposals
have taken advantage of the padata fields in KDC messages, while other 
proposals  have used the authorization data elements.

It seems likely that future Kerberos work will continue to make use of
Kerberos extensibility features. The working group has received
 pressure for some extensibility features in the current
draft.  There was a significant desire to better explain and define
how authorization data worked; that text has been in the draft for
a few years.  Several groups indicate they need ticket extensions,
and while not in the current draft, they have been in past
drafts; it seems unlikely that we will get consensus on a
specification that does not provide ticket extensions.  We also need
extensibility in character set choice (UTF8 support).  So it is
clear that at least some extensibility features will be needed.

In order to evaluate what extensibility mechanisms the Kerberos
protocol needs we need to weigh the costs of adding/keeping these
mechanisms against the costs of not including them.  We cannot predict
the future to know how much it costs to leave a particular feature out
of the protocol but we can  consider similar protocols and look at how
they have evolved over time.  It turns out that Kerberos Version 4
proves enlightening in this regard; in many ways Kerberos 4 is like
Kerberos 5 with all the extensibility options removed.

Despite the lack of extensibility features in the protocol, several
extensions were added to Kerberos 4 by various vendors.  Some vendors
added preauthentication.  Others added support for an exponential
lifetime mechanism to better take advantage of the byte Kerberos 4
allocated for storing ticket lifetime.  Other vendors ignored the IP
address field so they could forward Kerberos tickets.  Some
implementations added support for smart cards.  None of these
extensions were anticipated in the original Kerberos 4 protocol.  From
this we find that vendors can often shape a protocol to meet their
needs even when they go beyond the scope of the original design.

However we learn another important lesson when we look at
interoperability between Kerberos 4 implementations.  Since the
extension mechanisms were not designed into the protocol, little
thought was put into making sure extensions were only used between
peers that both supported the extension.  Significant interoperability
problems existed between some implementations; long lifetime tickets
were notoriously problematic.  Applications that expect to be able to
forward Kerberos 4 tickets do not work in realms where the KDC expects
to be able to check IP addresses.  Realms expecting preauth cannot
easily interoperate with other realms; in addition, if another
implementation were to use the same extensibility mechanism then
significant interoperability problems would be created.  So We do run a
risk that if our extension mechanisms are inadequate, we may find that
implementations cannot interoperate using the extensions, and worse
that implementations cannot negotiate with peers to find out what
capabilities are present.

Since there is a significant cost to providing insufficient
extensibility, we must consider the tradeoff between this cost and the
costs of adding extensibility.  When we add extensibility, it
increases the complexity of our design.  It also increases testing
complexity.  We propose that at a minimum, we need to make sure our
protocol is sufficiently extensible to meet the needs of proposals
under serious discussion.  This should certainly include making sure
that we have enough extensibility features for proposals that have
reached draft form.  As I mentioned earlier, we believe we have
specific ASN.1 that accomplishes this goal.

However vendor extensibility is not the only argument motivating
extensibility features in Kerberos.  We also need to make sure that
the IETF can make backward-compatible changes to the protocol in the
future.  I think many people were shocked when Tom pointed out in
Minneapolis that we cannot ever increment the Kerberos protocol
version number without making it impossible for old versions to
interoperate with new versions.  It turns out that we have been able
to propose solutions for all the changes that we desire to make.
However, as we have evaluated some of these proposals, we have
realized that we need to be careful; some extension options we have
proposed may make it more difficult for us in the future.  So we
should also consider how the Kerberos protocol can evolve when we look
at extensibility and make sure we add enough extensibility features
that we do not box ourselves into a corner.

In conclusion, as discussed in London, we believe that we need to look
at how we handle protocol extensibility for Kerberos.  We want to
balance the needs of vendors trying to get features to market in a
compatible manner against the complexity of protocol extensions.  We
also need to keep in mind the IETF's need to be able to come back to
the protocol in the future and preserve interoperability.

In the next message, I plan to argue that we need to consider all the
extensibility features together.  We cannot proceed as we have in the
past--adding ticket extensions here, removing some fields there.  We
certainly cannot ignore the problem of capability negotiation;
whenever an extension is used, the using party should be able to know
how the extension will be handled by the receiver.

Until recently, the Kerberos revisions work has focused on individual
extensions rather than examining extensibility as a general problem.
So far, our track record has not been very good.

Before the first draft of RFC 1510bis was released, people were
already proposing extensions: At IETF38, there was initial discussion
of adding checksums to Kerberos errors.  That discussion went forward
under the mistaken assumption that fields can be added to the end of
an ASN.1 sequence with no thought given to backward compatibility.
The proposal was integrated into the revisions draft, but recently
removed from section 5 by Tom, even though the feature is still
important .

Later at IETF39, the idea of ticket extensions was introduced.
Especially because tickets are stored by implementations for use in
later protocol exchanges, this extension mechanism has been very
problematic.  It was added again under the assumption that fields can
be added to ASN.1 sequences.  Later people believed that some
implementations might drop the ticket extensions; it was felt this
might be acceptable.  However still later we realized that
implementations would likely reject the ticket completely and so
ticket extensions have been removed from the ASN.1 pending a better
solution.

At several points, facets of the problem of authenticated cleartext
have been raised.  The krb-error checksums are one instance of this
problem.  Another early instance of this problem is the proposal to
include individual checksums of ticket extensions in the authorization
data associated with a ticket in order to integrity protect these
extensions.  Recently, WG members working with Packet Cable have
indicated interest in a checksum to protect the AS reply.  However
this issue has not been considered as a general problem.  People
looked at protecting the small part of the protocol that they were
concerned about.  There was not even a consistent method used to
protect all the protocol elements.

we also attempted to clarify how authorization data was used.  This
was first discussed at IETF39.  While much of this text is in the
current draft, few if any implementations comply with the text.  In
particular, both Heimdal and the MIT implementation seem to ignore
authorization data they do not understand rather than rejecting
authorization.  There is no negotiation mechanism provided to
distinguish between implementations that will reject ticket
authorization elements they do not understand from those who will
accept them.  While the discussion at IETF39 claimed interoperability
with old code is important, I do not believe that the clarification of
authorization data has been handled in a manner that is likely to lead
to both useful interoperability and availability of the new features.  

There are several general problems that seem to be common to many of
these attempts at extensibility.  One is that we have traditionally
not had a good understanding of ASN.1 and so we have failed to
understand how to extend it.  Another problem is that we have actively
tried to avoid negotiation of capabilities.  Unfortunately we have
paid a price for avoiding this negotiation: we want several features
that depend on knowing whether the other side of an interaction
supports the feature.  Without negotiation, implementers will have an
unpleasant choice when they consider using features like ticket
extensions.  They can use the feature, in which case their packet will
likely be discarded by old implementations, or they can maintain
interoperability and not use the new feature.

So since we value interoperability, we must consider how clients will
perform capability negotiation to inform the KDC of their capabilities
and learn the capabilities of the target service.  In addition if
there are reasonable ways we can achieve our goals while using ASN.1
correctly, we should do so.  We must at least use ASN.1 well enough
that we can maintain interoperability and have well-defined semantics.

Recently discussion in the working group has acknowledge that some
negotiation is necessary for some of the extensions being discussed.
However the trend has been to continue to treat each extensibility
feature as a distinct extension and to separate their specification
and design.  For example the most recent UTF8 discussion has focused
exclusively on UTF8 and the proposals to find out whether the KDC
supported UTF8 have been specific to that problem.  We believe this is
not the direction the working group should take for two reasons.
First, it has not worked well in the past.  But more importantly,
Kerberos's design does not lend itself to haphazard capability
negotiation.  Kerberos involves three parties: the client, the KDC and
the service.  For features like ticket extensions or UTF8 to be
useful, the client needs to discover the capabilities of the service
from the KDC.  Keeping state about the service's capabilities up to
date on the KDC is difficult.  We might be able to keep one or two
bits of state, but we do not want to record a generalized set of
service capabilities in the KDC entry.

			 Outline of Solution

So how can we do better with a general solution?  As we discussed in a
previous message, we have two primary goals.  We want to make sure
that there is sufficient extensibility for current proposals to be
implemented and enough extensibility for the IETF to make future
changes.  We also have a secondary goal of solving the authenticated
cleartext problem.

As we discussed in London we believe we can achieve these goals by
taking advantage of ASN.1 choices and constraints.  We can replace the
existing types with choices that wrap the types with appropriate
constraints.  The choice will have two arms, one for backward
compatibility and one for the new type.  The new types will include
appropriate typed holes for ticket extensions and for other PDUs that
can use this form of extensibility.  Since the choice is wrapping the
same common type, the old type will also have these fields, but the
ASN.1 constraint will make sure they are not included.  This should
meet our first goal.

In addition, ASN.1 extensibility markers are added to many types.  We
specify that new implementations must ignore elements added to
sequences while preserving them if the PDU is reencoded or included in
another PDU.  These extension markers can only be used by IETF action
because we need to carefully control assignment of tag numbers and
ordering within the sequences in order to maintain interoperability.
This simple change provides a powerful solution to the second goal.

It turns out that the choice types are made a bit more complex by the
desire to solve the authenticated cleartext problem.  We are fairly
certain that this is the simplest reasonable solution to that problem
but it does add complexity.  If the working group decides that the
authenticated cleartext problem does not need to be solved,this
complexity can be removed.  Unfortunately, if we decide to add a
solution to authenticated cleartext at any later point, it becomes
more complex than the current proposal.

Of course, so far I've only managed to reduce extensibility to the
previously unsolved problem of negotiation.  If we knew when we could
use the new types, we could get all the extensibility benefits.  The
hardest parte of negotiation is the initial AS-REQ message.  The
client needs to have a way to send a message that will be interpreted
by a new KDC as a new message potentially using extensibility like
UTF8 but is still readable by an old KDC.  I will describe that part
of the proposal in a later message along with the detailed mechanism
for handling authenticated cleartext; for the moment let us assume
that an acceptable solution exists for  the initial AS-REQ message.
In order to  produce an answer, the KDC needs to know if the service
supports new or old format messages; there is no way around having
some mechanism to get this one bit of state.  

By looking at the AS-REP, the client knows the properties of the KDC.
If the client received a new style AS-REP,  then the KDC supports the
new messages.  Note that the client should get a new AS-REP from a new
KDC whenever it sends a new AS-REQ, regardless of the capability of
the service.  However, whether  or not the ticket in the service  is
a new or old format ticket will depend on  the capabilities of the
service.  So, by reading the one AS-REP, the  client knows  the
capabilities both of the KDC and the  initial service.

So far, this sounds disturbingly like the overly complex Minneapolis
proposal.  However, rather than duplicating types as in that proposal,
we are using ASN.1 choices.  Certainly someone using off-the-shelf
ASN.1 tools could simply parse the choice and get whatever data is in
the type.  Since the inner types are the same except for ASN.1
constraints and authenticated cleartext handling, even implementations
that hand-code parsers can easily use a common parsing path to decode
both old and new types.  Also, gratuitous changes like changing the
krb-safe body were never part of this proposal.

The negotiation handling for other messages is simple.  You can use
new messages when talking to a new service as identified by the ticket
type.  The krb-error message can be new in response to a new message.

We believe this proposal provides a reasonable balance between solving
the extensibility problems the working group has been struggling with
since before the first draft of Kerberos revisions, while minimizing
unnecessary complexity.
The outline of our proposal in the last message left a few important
details unspecified.  This message should fill in all details that are
not tied to a specific ASN.1 type.  The next and likely final message
will  include a krb5 ASN.1 module.

			  Client Negotiation

Clients need to find out whether their KDC supports the extensible  format
messages.  The easiest way for this to happen is for a client to have
cached whether its KDC supports the extensible messages.    If the client
knows it is talking to a new KDC then the client can simply send a extensible
AS-REQ message (the as-req2 arm of the choice).

As Nico has pointed out several times, we want to allow clients to
cache this state on a per-realm basis rather than per-KDC basis.  This
means that if any KDC in the realm claims to support extensible messages all
the KDCs in the realm MUST accept the extensible messages.  For staged
upgrades realms can first install KDCs that support the new messages
and after all KDCs are upgraded the realm can then start using the new
messages.  

However, if a client does not have information about a realm cached it
needs to send an AS-REQ that new KDCs will treat as a extensible message but
old KDCs will treat as an old message.  Our proposed solution is to
introduce PA-AS-REQ, a new padata type that is the encoding of a extensible
AS-REQ.     This element will be encoded as one of the padata elements
of the old AS-REQ.  

Old KDCs or new KDCs that are not responding to new messages yet will
ignore PA-AS-REQ padata elements.  Old KDCs already ignore padata they
do not understand.  New KDCs must ignore everything in the AS-REQ
besides the PA-AS-REQ element.  In particular, new KDCs only consider
the padata elements in the PA-AS-REQ's padata sequence.  They ignore
any padata elements in the outer AS-REQ other than the  PA-AS-REQ
element.    Clients MUST NOT send more than one PA-AS-REQ padata
element, MUST NOT send a PA-AS-REQ element inside another PA-AS-REQ
element and MUST NOT  send a PA-AS-REQ in a TGS-REQ.

If a KDC receives a new AS-REQ or a PA-AS-REQ in an old AS-REQ, then
it responds with an extensible AS-REP.  Otherwise it responds with an
old AS-REP.

For other messages, we follow the general rule that if you receive an
extensible message you should respond with an extensible message.
Specific per-message rules will be included along with messages but
AS-REQ is the only really interesting case.  As discussed in the
outline, tickets are somewhat special in that they convey information
about the capabilities of the service.  A KDC MUST NOT issue a ticket2
(extensible format ticket) for a service unless the KDC knows that
service supports extensible messages.  However, the encrypted part of
the ticket MAY use an extensible format if the service supports
extensible messages even if the client does not.  This way, if new
extensions are added to the encrypted part of a ticket, then services
supporting extensible messages can take advantage of these extensions
even when talking to old clients.

If multiple services or machines use the same principal, then the KDC
cannot issue ticket2 until all services using a particular principal
support Kerberos extensibility.  Thus, a new KDC MAY return a ticket1
inside an extensible KDC-REP.

		       Authenticated Cleartext

Before we describe how we handle authenticated cleartext, let's look
at how we would structure the ASN.1  ignoring the problem of
authenticated cleartext.  The following is  an example of an
extensible AP-REQ that does not support solving the authenticated
cleartext problem:

AP-REQ		::= CHOICE {
	ap-req1		[APPLICATION 14] AP-REQ-COMMON
				(WITH COMPONENTS {
					...,
					extensions ABSENT
					-- also excluding
					-- ASN.1 extensions
				}),
	ap-req2		[APPLICATION 18] AP-REQ-COMMON
}

AP-REQ-COMMON	::= SEQUENCE {
	pvno		[0] INTEGER,
	msg-type	[1] INTEGER,
	ap-options	[2] APOptions,
	ticket		[3] Ticket,
	authenticator	[4] EncryptedData -- Authenticator --,
	extensions	[5] ApReqExtensions OPTIONAL,
	...
}

As discussed  previously  the AP-req becomes a choice with  two
alternatives; one for RFC 1510 compatibility and one that supports
extensibility.  There are two basic approaches  for authenticated
cleartext: types can be wrapped  with a checksum in the wrapping type
or a checksum can be included in the type being checksummed.  Adding
checksums to the typed being checksummed creates significant
implementation complexity and is likely to lead to errors that
prohibit interoperability, so  we do not favor that option.  Instead,
we propose that the AP-REQ choice be as follows:

AP-REQ		::= CHOICE {
	ap-req1		[APPLICATION 14] AP-REQ-COMMON
				(WITH COMPONENTS {
					...,
					extensions ABSENT
					-- also excluding
					-- ASN.1 extensions
				}),
	ap-req2		[APPLICATION 18] Signed{AP-REQ-COMMON}
}

The Signed type is an ASN.1 parameterized type that expands to a sequence
containing an optional checksum and the type in braces.  Using the
parameterized type makes the ASN.1 much easier to read than having a
bunch of sequences for each signed type.  However, if the working
group is uncomfortable with this new ASN.1 syntax we can expand all
the instances of Signed before publication.  At least while actively
discussing the proposal we'd like to keep using Signed notation as it
is simpler to discuss.

All these checksums for wrapped types MUST be keyed checksums.  For
each message we will provide guidelines for when the checksum is
included and for what key is used.  Guidelines on when to include a
checksum are never ambiguous: a particular PDU is never correct both
with and without a checksum.  Implementations MUST reject messages
where a checksum is included and not expected or where a checksum is
expected but not included.

The AS-REQ is not protected by a checksum in a Signed type.  There is
not always a key available for this protection.  Instead, a checksum
of the AS-REQ is included in extensible KDC replies.

		      Extensibility Guidelines

[This part of the message is intended to go directly into the
revisions draft.  As such the tone is somewhat different.  Significant
parts of the rest of this messages and the earlier messages may form
basis for text going into revisions, but those sections will need
editing for tone and content.]

Kerberos provides two general mechanisms for protocol extensibility.
Many protocol messages contain typed holes--sub-messages that contain
an octet-string along with an integer that defines how to interpret
the octet-string.  The integer types are registered centrally, but can
be used both for vendor extensions and for extensions standardized in
the IETF.

Most messages also contain ASN.1 extension markers.  These markers
allow fields to be added in future versions of this specification.
Because tag numbers and order in the sequence need to be agreed on in
order to maintain interoperability, implementations MUST NOT include
ASN.1 extensions except when those extensions are specified by IETF
standards-track documents.

		  x.x.1 Compatibility with RFC 1510

Implementations of RFC 1510 did not use extensible ASN.1 types.
Sending additional fields not in RFC 1510 to these implementations
results in undefined behavior.  Examples of this behavior are known to
include discarding messages with no error indications.

Where messages have been changed since RFC 1510, ASN.1 choice types
are used; one arm of the choice provides a message compatible with RFC
1510 and the other arm provides the current, extensible message.  

Implementations sending new messages MUST insure that the recipient
supports these new messages.  Along with each extensible message is a
guideline for when that message MAY be used.  IF that guideline is
followed, then the recipient is guaranteed to understand the message.

		  x.x.2  Sending Extensible Messages

Care must be taken to make sure that old implementations can
understand messages sent to them even if they do not understand an
extension that is used.  Unless the sender knows the extension is
supported, the extension cannot change the semantics of the core
message or previously defined extensions.

For example, an extension including key information necessary to
decrypt the encrypted part of a KDC-REP could only be used in
situations where the recipient was known to support the extension.
Thus when designing such extensions it is important to provide a way
for the recipient to notify the sender of support for the extension.
For example in the case of an extension that changes the KDC-REP reply
key, the client could indicate support for the extension by including
a padata element in the AS-REQ sequence.  The KDC should only use the
extension if this padata element is present in the AS-REQ.  Even if
policy requires the use of the extension, it is better to return an
error indicating that the extension is required than to use the
extension when the recipient may not support it; debugging why
implementations do not interoperate is easier when errors are
returned.

		 x.x.3 Receiving Extensible Messages

Recipients of  unknown message extensions (either in typed
holes or ASN.1 types) should preserve the encoding of the extension
but otherwise ignore the presence of the extension.  If the message is
used later--for example, when a ticket is later used in an
AP-REQ--then the unknown extensions MUST be included.

There is one exception to this rule.  If an unknown authorization data
element type is received by a server either in an AP-REQ or in a
ticket contained in an AP-REQ, then the authentication SHOULD fail.
Authorization data is intended to restrict the use of the ticket.  If
the service cannot determine whether the restriction applies to that
service then a security weakness may result if the ticket can be used
for that service.  Authorization elements that are optional can be
enclosed in the AD-IF-RELEVANT element.

Many RFC 1510 implementations ignore unknown authorization data
elements.  Depending on these implementations to honor authorization
data restrictions may  create a security weakness.

So our proposal on Kerberos extensibility has generated a fair bit of
traffic; enough that if we aren't careful details may get dropped in
the messages flying back and forth.  Since a lot of important points
have been raised I'd like to make sure that doesn't happen.  Here is
my list of open issues and fixes brought up on the list so far.  If
you brought up some point that is either still open or requires a
change be made, please make sure it is here.

			     Open Issues

* Jeff Altman should be posting a summary of questions related to how
  this all fits into UTF8.  That should lead to a response to John's
  comment about  KerberosString definition.

* We need to decide if we expand  the Signed types.

* We need to come up with a concrete proposal on multiple
  implementations with a single ccache, especially looking at
  forwarding.

* We need to look at how this works for U2U.  I plan to sit down with
  Tom and Ken, walk through a U2U session  and double check what
  happens there; then  we should have a reasonable solution to
  propose.

* Need to deal with direction address types.

* We need to look at tr-encoding.

* I need to send out KRB-ERROR guidelines.

* I think there may be a few missing extension markers in the ASN.1
  module; I will talk to Tom about this.

* Document proper handling of unknown flags.

				Fixes
Here are fixes proposed on the list there seem to be no objections to:

* Add nonce to KRB-ERROR

* Add pa-as-req padata possibility for errors.

* Addresses   of unknown families should be accepted by KDC

---

From: [email-masked] (Sam Hartman)
Date: Wed, 10 Sep 2003 18:16:30 -0400 (EDT)

several people have asked what the extensions proposal is.

this all got started with a presentation Tom, Ken and I made before
IETF 52.  I encourage you to take a look at the minutes and slides for
that meeting.  

The following January John Brezak made it clear that we needed to come
up with a clarifications document.  Over the next few meetings, I
believe the working group came to a rough consensus on the goals of
extensions,  but not on the specific details of the IETF 52 proposal.

We're likely to basically re-propose the same goals and motivations,
and do many of the same things.  However Nico and Tom have been
working on ASN.1, and I suspect the ASN.1 proposal may end up looking
somewhat different than what we brought to IETF 52.

Of course  someone may come forward with alternative proposals for
what extensions should do.

Remember that the guiding principle--and I'm fairly certain we have
consensus on this--is that extensions should enable new technologies
like PFS, avoiding timestamp dependence, and others, but should not
actually contain unnecessary new features.  There are a few
things--like fixing the authenticated plaintext problem that need to
go into the extensions document itself.  There are other things, like
cross-realm referals that we agreed to bring into extensions the
protocol, although probably not extensions the base spec.

The minutes of IETf 53 have a good description of what we have agreed
to do for extensions and what we decided to do for clarifications.
It's kind of neat to see that we seem to have accomplished those goals
for clarifications.

I think since IETf 53, we have achieved consensus that we want to
solve the authenticated cleartext problem.  This is not really because
someone has actually advanced any new arguments, but more because
those who were not convinced of the value of solving authenticated
cleartext seem no longer to be actively involved in the WG.  Also,
several of us who believed it was a good idea but were not convinced
it was required are now convinced it is essential.  Finally, the Cable
Labs folks--who originally drove the desire to solve authenticated
cleartext--seem even more involved in the WG now than they did before.

In a follow up to this message, I'll post the text of the December
2001 proposal.  Note that it is somewhat dated, and has been
superceeded by the discussions at IETf 52 and IETf 53.  However it is
somewhat more complete for those trying to get background than the
minutes of the meetings.  The slides for IETf 52 are probably useful
as a brief intro.

--Sam