Subject: RE: Status update for Kerberos Revisions

From: Jeffrey Altman <[email-masked]>
Date: Wed, 14 Nov 2001 16:49:58 EST

> On Wed, 14 Nov 2001, John Brezak wrote:
> 
> > [Jbrezak] Agreed. Just realize that what is there will need to
> > interoperate. You cannot tell them to
> > limit their names to only ascii characters.
> 
> Indeed, we can, and that's exactly what Jeff Altman's draft does.  Of
> course, we can't expect them to actually _listen_, but people who limit
> themselves to US-ASCII are going to have less pain both before and during
> transition.

Just as a point of reference since it will be a few days until the
draft shows up in the I-D directory, here is the submitted draft.  It
is not intended to penalize Microsoft's implementation.  Nor do I
believe that it does so.  The current situation is that Microsoft's
choice of character set is just as arbitrary as any other choice of
character set that was in use before Microsoft shipped Windows 2000.

The point of the extensions is not to define what the proper behavior
of GeneralString is, but to define what the proper behavior of
KerberosString will be.  If you receive a KerberosString using Choice
UTF8String then you will be sure of what you are getting.
Otherwise, you will be just as confused about the meaning of the
character set in the GeneralString as you are now.  

John, when a Windows 2000 system receives a GeneralString encoded in
ISO Latin2, Code Page 437 or JIS, how does it behave?  

Does it return an error?  If so, what?

We must expect that the behavior in the future which be identical to
the way it is today.

- Jeff

INTERNET-DRAFT                                           Jeffrey Altman
<draft-ietf-kerberos-info-ascii-gen-string-00.txt>  Columbia University
November 13, 2001
Expires: May 13, 2002

Informational: Kerberos GeneralString to be Interpreted as ASCII Only

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Distribution of this memo is unlimited.  It is filed as 
   draft-ietf-kerberos-info-ascii-gen-string-00.txt, and expires on 
   May 13, 2001.  Please send comments to the Kerberos Working Group
   mailing list.

Abstract:

   To ensure future interoperability between existing deployments
   of Kerberos 5 (RFC 1510) and future standards efforts the 
   Kerberos Working Group strongly recommends that users of Kerberos 5
   implementations SHOULD NOT deploy Kerberos principal or service
   names that utilize characters not included in the 94 printable 
   characters specified in the International Reference Version of
   ISO-646/ECMA-6 (aka U.S. ASCII).

Background:

   The original specification of the Kerberos protocol in RFC 1510 uses
   GeneralString in numerous places for human-readable string data. 
   Historical implementations of Kerberos cannot utilize the full power
   of GeneralString. This ASN.1 type requires the use of designation 
   and invocation escape sequences as specified in ISO-2022/ECMA-35 to
   switch character sets, and the default character set that is designated
   for G0 is the ISO-646/ECMA-6 International Reference Version (IRV) (aka 
   U.S. ASCII), which mostly works.

   ISO-2022/ECMA-35 defines four character-set code elements (G0..G3) and 
   two Control-function code elements (C0..C1).  DER prohibits the 
   invocation of character sets into any but the G0 and C0 sets.
   Unfortunately, this seems to have the side effect of prohibiting the
   use of ISO-8859 (ISO Latin) character-sets or any other character-sets
   that utilize a 96-character set, since it is prohibited by ISO-2022/
   ECMA-35 to invoke them into the G0 code element. 

   In practice, many implementations treat GeneralStrings as if they were
   8-bit strings of whichever character set the implementation 
   defaults to, without regard for correct usage of character-set 
   designation escape sequences.  The default character set is often 
   determined by the current user's operating system dependent locale.  
   At least one major implementation places unescaped UTF-8 encoded 
   Unicode characters in the GeneralString.   This failure to adhere to
   the GeneralString specifications results in interoperability issues 
   when conflicting character encodings are utilized by the Kerberos
   clients, services, and KDC.

   This unfortunate situation is the result of improper documentation
   of the restrictions of the ASN.1 GeneralString type in prior 
   Kerberos specifications.  
   
Transitioning to the use of UTF-8:

   For various reasons, a transition to the use of UTF-8 encoding is
   desirable.  First, there is a mandate from the IESG to support
   international character sets generally, and UTF-8 specifically.  
   Also, the fact that there are existing installations violating the 
   ISO-646/ECMA-6 restrictions and accepting the resulting pain indicates
   that there is a clear need to support alternate character sets in 
   princpal names and passwords.  As I8N support is deployed in DNS
   there will be a need to represent Unicode service names.

   At the same time, backward compatibility with the existing installed
   base is crucial.  Few site administrators have the luxury of declaring a
   flash cut-over of all users, applications, servers, etc to an incompatible
   protocol -- many have non-local users over whom they have little or no
   control.  To this end, it is important for new implementations to be able
   to tell whether a particular non-US-ASCII string was encoded as UTF-8 by a
   new implementation, or as something else by an old implementation.  In the
   latter case, it is of course impossible to know what the "something else"
   is without being told in advance.

   There have been three proposals for how the fields currently encoded
   as GeneralStrings should be interpreted in order to accomplish such 
   a transition:

   (1) Lie.  Start using UTF-8, but continue to encode all of these
       fields as GeneralStrings.  To my knowledge, this is what Microsoft
       is doing today.  This approach is attractive because it requires
       no changes to the message format specification and provides 100%
       compatibility with deployments that adhere to the ISO-646/ECMA-6
       standards.   However, it has several key problems.  First, it does
       not allow a new implementation to tell whether a particular string
       was encoded as UTF-8 by a post-RFC-1510 implementation or as some 
       8-bit local character set by an older implementation.  Second, 
       there are potential problems with encoding arbitrary 8-bit strings,
       particularly for those who are using off-the-shelf ASN.1 compilers.
       Finally, violating the ASN.1 specification in this manner would be 
       unpopular with the ITU which is a serious issue.

   (2) Don't lie.  Start using UTF-8 encoded in GeneralStrings with
       ISO-2022/ECMA-35 compatible escape sequences.  While this has the
       appearance of following the ASN.1 specification for GeneralString, 
       it has the problem that UTF-8 cannot be legally encoded due to the
       restriction that only G0 compatible character-set can be specified.
       This creates problems for implementors using off-the-shelf ASN.1 
       compilers as well as political issues with the ITU.

   (3) Don't use GeneralString.  In all the places where we currently
       use GeneralString, begin using a new "KerberosString" type instead.
       This type would be defined as an ASN.1 choice, with GeneralString
       and some form of UTF-8 strings as alternatives.  The selection of
       which alternative to use would be based on whether one was talking
       to an old implementation or a new one.  This approach does involve
       changing the message format _specifications_, but as long as the
       GeneralString choice is used, the actual ASN.1 DER encoding does
       not change.  There is a transition issue in that replacing a type
       with a choice containing that type is not always a legitimate thing
       to do, but as long as DER are used (which is always the case in 
       Kerberos 5), it does work correctly.

       The new KerberosString could be implemented as one of:

         KerberosString ::= CHOICE {
                              general GeneralString (VisibleString),
                              utf8 UTF8String
         }

       or as

         KerberosString ::= CHOICE {
                              general GeneralString (VisibleString),
                              ...
         }

      In both cases, most (if not all) occurrences of GeneralString 
      would be replaced with the new KerberosString.

   It is the belief of the Kerberos Working group that regardless of the
   final decision that is reached on how to transition to the use of UTF-8
   those implementors and deployments which have restricted their use of
   character-sets to the ISO-646/ECMA-6 IRV will have significantly fewer
   difficulties making the transition.  This is because the IRV is a proper
   subset of the UTF-8 encoding.

Security Considerations:

   Interoperability conflicts can result in denial of service for clients
   that utilize character-sets in Kerberos strings other than those stored
   in the KDC database.  

References:

   RFC-1510         The Kerberos Network Authentication Service (V5)
   ISO-646/ECMA-6   7-bit Coded Character Set
   ISO-1022/ECMA-35 Character Code Structure and Extension Techniques
   ISO-4873/ECMA-43 8-bit Coded Character Set Structure and Rules
   RFC-2279         UTF-8, a transformation format of ISO-10646

Acknowledgements:

   This document while edited by Jeffrey Altman <[email-masked]>
   (Columbia University) was directly derived from e-mail discussions 
   with Jeffrey T. Hutzelman <[email-masked]> (CMU) and Tom Yu <[email-masked]>
   (MIT).

 Jeffrey Altman * Sr.Software Designer      C-Kermit 8.0 Beta available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 [email-masked]          OpenSSL.  SSH soon to follow.

---

From: "John Brezak" <[email-masked]>
Date: Thu, 15 Nov 2001 09:35:32 -0800

below [JBrezak]

-----Original Message-----
From: Jeffrey Altman [mailto:[email-masked]] 
Sent: Wednesday, November 14, 2001 1:50 PM
To: Jeffrey Hutzelman
Cc: John Brezak; Clifford Neuman; [email-masked]
Subject: RE: Status update for Kerberos Revisions

> > interoperate. You cannot tell them to limit their names to only 
> > ascii characters.
> 
> course, we can't expect them to actually _listen_, but people who 
> limit themselves to US-ASCII are going to have less pain both before 
> and during transition.

Just as a point of reference since it will be a few days until the draft
shows up in the I-D directory, here is the submitted draft.  It is not
intended to penalize Microsoft's implementation.  Nor do I believe that
it does so.  The current situation is that Microsoft's choice of
character set is just as arbitrary as any other choice of character set
that was in use before Microsoft shipped Windows 2000.

[JBrezak] Are there any other implementations that use character set
encodings with Kerberos GeneralStrings other than ascii or Unicode? We
should recognize the scope of the problem and work to come to a
resolution around a few specific cases. I would like to see that a new
KDC be able to recognize a Win2000 client that is using non-ASCII
characters (unicode) in principal names. Something like - the *old*
GeneralString can be encoded as UTF-8 unicode or the 7-bit ascii
character sets. This would satisfy my requirement for interoperability.

The point of the extensions is not to define what the proper behavior of
GeneralString is, but to define what the proper behavior of
KerberosString will be.  If you receive a KerberosString using Choice
UTF8String then you will be sure of what you are getting. Otherwise, you
will be just as confused about the meaning of the character set in the
GeneralString as you are now.  

John, when a Windows 2000 system receives a GeneralString encoded in ISO
Latin2, Code Page 437 or JIS, how does it behave?  

[JBrezak] Do you mean as an escaped string? If so I'm checking.

We must expect that the behavior in the future which be identical to the
way it is today.

[JBrezak] But I'm very concerned when old clients talk to new KDCs and
servers. Also when new clients talk to old KDCs and servers.

- Jeff

Status of this Memo

Abstract:

Background:

   The original specification of the Kerberos protocol in RFC 1510 uses
   GeneralString in numerous places for human-readable string data. 
   Historical implementations of Kerberos cannot utilize the full power
   of GeneralString. This ASN.1 type requires the use of designation 
   and invocation escape sequences as specified in ISO-2022/ECMA-35 to
   switch character sets, and the default character set that is
designated
   for G0 is the ISO-646/ECMA-6 International Reference Version (IRV)
(aka 
   U.S. ASCII), which mostly works.

   ISO-2022/ECMA-35 defines four character-set code elements (G0..G3)
and 
   two Control-function code elements (C0..C1).  DER prohibits the 
   invocation of character sets into any but the G0 and C0 sets.
   Unfortunately, this seems to have the side effect of prohibiting the
   use of ISO-8859 (ISO Latin) character-sets or any other
character-sets
   that utilize a 96-character set, since it is prohibited by ISO-2022/
   ECMA-35 to invoke them into the G0 code element. 

   In practice, many implementations treat GeneralStrings as if they
were

   ISO-646/ECMA-6 restrictions and accepting the resulting pain
indicates

   At the same time, backward compatibility with the existing installed
   base is crucial.  Few site administrators have the luxury of
declaring a
   flash cut-over of all users, applications, servers, etc to an
incompatible
   protocol -- many have non-local users over whom they have little or
no
   control.  To this end, it is important for new implementations to be
able
   to tell whether a particular non-US-ASCII string was encoded as UTF-8
by a
   new implementation, or as something else by an old implementation.
In the
   latter case, it is of course impossible to know what the "something
else"
   is without being told in advance.

   (1) Lie.  Start using UTF-8, but continue to encode all of these
       fields as GeneralStrings.  To my knowledge, this is what
Microsoft
       is doing today.  This approach is attractive because it requires
       no changes to the message format specification and provides 100%
       compatibility with deployments that adhere to the ISO-646/ECMA-6
       standards.   However, it has several key problems.  First, it
does
       not allow a new implementation to tell whether a particular
string
       was encoded as UTF-8 by a post-RFC-1510 implementation or as some

       8-bit local character set by an older implementation.  Second, 
       there are potential problems with encoding arbitrary 8-bit
strings,
       particularly for those who are using off-the-shelf ASN.1
compilers.
       Finally, violating the ASN.1 specification in this manner would
be 
       unpopular with the ITU which is a serious issue.

   (2) Don't lie.  Start using UTF-8 encoded in GeneralStrings with
       ISO-2022/ECMA-35 compatible escape sequences.  While this has the
       appearance of following the ASN.1 specification for
GeneralString, 
       it has the problem that UTF-8 cannot be legally encoded due to
the
       restriction that only G0 compatible character-set can be
specified.
       This creates problems for implementors using off-the-shelf ASN.1 
       compilers as well as political issues with the ITU.

   (3) Don't use GeneralString.  In all the places where we currently
       use GeneralString, begin using a new "KerberosString" type
instead.
       This type would be defined as an ASN.1 choice, with GeneralString
       and some form of UTF-8 strings as alternatives.  The selection of
       which alternative to use would be based on whether one was
talking
       to an old implementation or a new one.  This approach does
involve
       changing the message format _specifications_, but as long as the
       GeneralString choice is used, the actual ASN.1 DER encoding does
       not change.  There is a transition issue in that replacing a type
       with a choice containing that type is not always a legitimate
thing
       to do, but as long as DER are used (which is always the case in 
       Kerberos 5), it does work correctly.

       or as

   It is the belief of the Kerberos Working group that regardless of the
   final decision that is reached on how to transition to the use of
UTF-8
   those implementors and deployments which have restricted their use of
   character-sets to the ISO-646/ECMA-6 IRV will have significantly
fewer
   difficulties making the transition.  This is because the IRV is a
proper
   subset of the UTF-8 encoding.

Security Considerations:

   Interoperability conflicts can result in denial of service for
clients
   that utilize character-sets in Kerberos strings other than those
stored
   in the KDC database.  

References:

Acknowledgements:

   This document while edited by Jeffrey Altman <[email-masked]>
   (Columbia University) was directly derived from e-mail discussions 
   with Jeffrey T. Hutzelman <[email-masked]> (CMU) and Tom Yu
<[email-masked]>
   (MIT).

 Jeffrey Altman * Sr.Software Designer      C-Kermit 8.0 Beta available
 The Kermit Project @ Columbia University   includes Secure Telnet and
FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 [email-masked]          OpenSSL.  SSH soon to
follow.

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 15 Nov 2001 12:52:55 EST

> below [JBrezak]

inline response

> character sets. This would satisfy my requirement for interoperability.

The scope of the problem is that current Kerberos implementations do
not restrict user input to 7-bit ASCII.  There are some but not many
sites that do indeed use ISO-8859 character sets when specifying their
user principal names.

We have no idea how many people use non-ASCII characters as part of
their passwords.

> [JBrezak] Do you mean as an escaped string? If so I'm checking.

Not an escaped string.  No one uses escapes.  Part of the problem is
that even escaping to an ISO-8859 character set is illegal in
GeneralString. 

It is possible that you can receive a string from a client that is
just a set of octets whose input was any arbitrary ISO character-set
or OEM code page.

> servers. Also when new clients talk to old KDCs and servers.

So are we all.  None of these changes can take place in vacuum.  If we
can't tell a new message from an old one we are in deep trouble.  It
is at that point where the version number must be incremented.

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 19 Nov 2001 12:19:22 EST

> inline [JBrezak]

inline

> Sent: Thursday, November 15, 2001 9:53 AM
> To: John Brezak
> Cc: Jeffrey Hutzelman; Clifford Neuman; [email-masked]
> The scope of the problem is that current Kerberos implementations do not
> restrict user input to 7-bit ASCII.  There are some but not many sites
> that do indeed use ISO-8859 character sets when specifying their user
> principal names.
> 
> [JBrezak] What is missing from the I-D is how to handle Unicode
> characters as GeneralStrings. Currently they are encoded as UTF-8.
> Windows 2000 does not use different character sets - just Unicode.

John, the whole point of the draft is that you cannot place Unicode
characters into GeneralStrings.  GeneralStrings are only allowed to
store characters from ISO-646 compliant character sets.  There is no 
method for placing any form of Unicode in these strings.  If there
were, we would not be in such a bind and I would not need to publish
an Informational draft stating

  DO NOT USE ANYTHING OTHER THAN 7-BIT ASCII FOR ANY FORM OF 
  DATA ENTRY.  NOT NAMES, NOT PASSWORDS, ...

> [JBrezak] Nor do I. Currently the DES types are ambiguous as to what the
> input form is for the string2key function. This should also be called
> out in your I-D and definitely handled in the kerberos-revisions. When
> Windows 2000 is using the RC4-HMAC enctype, the defined string2key
> function always requires a Unicode string as the input.

Which may also be a problem.

> can't tell a new message from an old one we are in deep trouble.  It is
> at that point where the version number must be incremented.
> 
> [JBrezak] What will happen with other existing implementations with they
> get UTF-8 encoded GeneralStrings? Do they return an ASN.1 decode error? 
> I would still like to see that GeneralStrings in Kerberos are ASCII7 or
> UTF-8 Unicode characters when escapes are not specified. Are there any
> implementations that do other than that? 

A proper ASN.1 parser will return a decode error.  Of course, the
parsers in MIT Kerberos do not.

We have already been told by the powers that be that we may not ignore
the definition of GeneralString as per ASN.1.  The IESG and the ITU
will now allow it.  Back at Pittsburgh when this problem was first
recognized that is the path ath Tom, Jeff, Ken and I wanted to
pursue.  It was not accepted.

---

From: "John Brezak" <[email-masked]>
Date: Tue, 20 Nov 2001 11:05:38 -0800

RFC-2279 describes how ISO-10646 (Unicode) is handled as UTF-8.

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Tuesday, November 20, 2001 10:59 AM
To: Tom Yu
Cc: John Brezak; [email-masked]; [email-masked]
Subject: Re: Status update for Kerberos Revisions

>>>>> "Tom" == Tom Yu <[email-masked]> writes:

    Tom> I seem to recall that the encoding of the Unicode isn't
    Tom> specified.  Is it UTF-8?

no, utf16.

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 20 Nov 2001 14:15:39 EST

> 
> >>>>> "John" == John Brezak <[email-masked]> writes:
> 
> John> [JBrezak] GeneralString can contain any character set as long as 
> John> it is properly escaped. The "properly escaped" is the part that 
> John> many people have missed in many places even outside of Kerberos. 
> John> In fact many protocols have stayed away from GeneralString just 
> John> because of this.  GeneralString can contain UTF-8 characters as 
> John> long as they are prefixed with the correct escape sequence.
> 
> It may not.  The definition of GeneralString in Clause 36, Table 3 of
> X.680(1997) defines GeneralString to include "All G and C sets + SPACE
> + DELETE".  Nowhere does it say anything about encoding outside of ISO
> 2022.  UTF-8 isn't a G set or a C set.  It is a completely different
> encoding.  Furthermore Clause 8.20.5.1 of X.690(1997) specifies that "An
> escape sequence shall not be used unless it is one of those specified by
> the registrations numbers used to define the character string type in
> ITU-T Rec. X.680|ISO/IEC 8824-1".  I interpret this to exclude escapes
> to other encoding schemes.  UTF-8 isn't an ISO 2022 character set; it is
> a completely different encoding from ISO 2022.
> 
> [JBrezak] There is a registered UTF-8 escape sequence at
> http://www.itscj.ipsj.or.jp/ISO-IR/196.pdf . ISO 10646 is the equiv to
> ISO 2022 for Unicode.

This is what I was saying and arguing for two years ago.  But it does
not apply here.   ASN/1 GeneralString does not permit any ISO-2022
escape to be used.  It only permits a restricted subset of ISO-2022 to
be used.  That restriction limts the allowed character-sets are
limited to those 94-character sets which can be stored in G0 or C0.
This rules out all of the ISO-8859 setsass well as all those which can
be accessed via escapes to non-ISO-2022 character-sets.

> John> [JBrezak] Unicode is used in the string2key function for RC4-HMAC 
> John> only.  For DES, the input form is not specified in 1510.
> 
> I seem to recall that the encoding of the Unicode isn't specified.  Is
> it UTF-8?
> 
> [JBrezak] Unicode with 16-bit characters is specified in the RC4-HMAC
> I-D.

with or without a byte order mark? 

if no BOM, which byte order?

---

From: "John Brezak" <[email-masked]>
Date: Tue, 20 Nov 2001 11:41:03 -0800

Finishing part of this thread - [JBrezak]

-----Original Message-----
From: Jeffrey Altman [mailto:[email-masked]] 
Sent: Tuesday, November 20, 2001 11:16 AM
To: John Brezak
Cc: Tom Yu; [email-masked]; [email-masked]
Subject: RE: Status update for Kerberos Revisions

> John> [JBrezak] Unicode is used in the string2key function for 
> John> RC4-HMAC

[JBrezak] From the I-D

The RC4-HMAC String to key function is defined as follow: 
    
   String2Key(password) 
    
        K = MD4(UNICODE(password)) 
         
   The RC4-HMAC keys are generated by using the Windows UNICODE version 
   of the password. Each Windows UNICODE character is encoded in 
   little-endian format of 2 octets each. Then performing an MD4 [6] 
   hash operation on just the UNICODE characters of the password (not 
   including the terminating zero octets).

---

From: "John Brezak" <[email-masked]>
Date: Tue, 20 Nov 2001 12:23:49 -0800

inline - [JBrezak]

-----Original Message-----
From: Jeffrey Altman [mailto:[email-masked]] 
Sent: Tuesday, November 20, 2001 11:16 AM
To: John Brezak
Cc: Tom Yu; [email-masked]; [email-masked]
Subject: RE: Status update for Kerberos Revisions

> encoding.  Furthermore Clause 8.20.5.1 of X.690(1997) specifies that 
> "An escape sequence shall not be used unless it is one of those 
> specified by the registrations numbers used to define the character 
> string type in ITU-T Rec. X.680|ISO/IEC 8824-1".  I interpret this to 
> exclude escapes to other encoding schemes.  UTF-8 isn't an ISO 2022 
> character set; it is a completely different encoding from ISO 2022.
> 

This is what I was saying and arguing for two years ago.  But it does
not apply here.   ASN/1 GeneralString does not permit any ISO-2022
escape to be used.  It only permits a restricted subset of ISO-2022 to
be used.  That restriction limts the allowed character-sets are limited
to those 94-character sets which can be stored in G0 or C0. This rules
out all of the ISO-8859 setsass well as all those which can be accessed
via escapes to non-ISO-2022 character-sets.

[JBrezak] Wow - how could we have missed this... 
So we are back to 2 proposals:

1) Your I-D with CHOICE:

For reference the class identitifiers are 27 for GeneralString and 12
for UTF8String.

Does UTF8String need to have constraints - I see that UniversalString
requires constraints.

2) Paul's proposal to just live with it and step back from formal ASN.1.

We need to weigh the needs of compatibility vs. strict standards
conformance. Again this was brought up in Minneapolis with the 5.1 vs.
5.2 proposal where just the minimum was to be added to 5.1 for the new
required features (this would be kerberos-revisions) and a new effort
with ASN.1 cleanup and such would be termed 5.1, which probably would
become Kerberos version 6.