Subject: Section 8 Kerberos Revisions for comment

From: Clifford Neuman <[email-masked]>
Date: Wed, 20 Sep 2000 09:11:07 -0700 (PDT)

Here is section 8 of the Kerberos specification for comment.

Clifford Neuman
-----

<H3>8.  Constants and other defined values</H3>

<H3>8.1.  Host address types</H3>

All negative values for the host address type are reserved for local
use.  All non-negative values are reserved for officially assigned
type fields and interpretations.

<P>

The values of the types for the following addresses are chosen to
match the defined address family constants in the Berkeley Standard
Distributions of Unix.  They can be found in <sys/socket.h> with
symbolic names AF_xxx (where xxx is an abbreviation of the address
family name).

<H5>Internet (IPv4) Addresses</H5>

Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in
MSB order.  The type of IPv4 addresses is two (2).

<H5>Internet (IPv6) Addresses [Westerlund]</H5>

IPv6 addresses are 128-bit (16-octet) quantities, encoded in MSB
order.  The type of IPv6 addresses is twenty-four (24). [RFC1883]
[RFC1884].

The following addresses (see [RFC1884]) MUST not appear in any
Kerberos packet:

<UL>
<LI>the Unspecified Address
<LI>the Loopback Address
<LI>Link-Local addresses
</UL>

IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2.

<H5>CHAOSnet addresses</H5>

CHAOSnet addresses are 16-bit (2-octet) quantities, encoded in MSB
order.  The type of CHAOSnet addresses is five (5).

<H5>ISO addresses</H5>

ISO addresses are variable-length.  The type of ISO addresses is seven (7).

<H5>Xerox Network Services (XNS) addresses</H5>

XNS addresses are 48-bit (6-octet) quantities,  encoded
in MSB order.  The type of XNS addresses is six (6).

<H5>AppleTalk Datagram Delivery Protocol (DDP) addresses</H5>

AppleTalk DDP addresses consist of an 8-bit node number and a 16-bit
network number.  The first octet of the address is the node number;
the remaining two octets encode the network number in MSB order.  The
type of AppleTalk DDP addresses is sixteen (16).

<H5>DECnet Phase IV addresses</H5>

DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order.
The type of DECnet Phase IV addresses is twelve (12).

<H5>Netbios addresses</H5>

Netbios addresses are 16-octet addresses typically composed of 1 to 15
characters, trailing blank (ascii char 20) filled, with a 16th octet
of 0x0.  The type of Netbios addresses is 20 (0x14).

<H3>8.2.  KDC messages</H3>

<H4>8.2.1.  UDP/IP transport</H4>

When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request
using UDP IP transport, the client shall send a UDP datagram
containing only an encoding of the request to port 88 (decimal) at the
KDC's IP address; the KDC will respond with a reply datagram
containing only an encoding of the reply message (either a KRB_ERROR
or a KRB_KDC_REP) to the sending port at the sender's IP address.
Kerberos servers supporting IP transport must accept UDP requests on
port 88 (decimal).   The response to a request made through UDP/IP
transport must also use UDP/IP transport.

<H4>8.2.2.  TCP/IP transport [Westerlund,Danielsson]</H4>

Kerberos servers (KDC's) should accept TCP requests on port 88 (decimal)
and clients should support the sending of TCP requests on port 88
(decimal).  When the KRB_KDC_REQ message is sent to the KDC over a TCP
stream, a new connection will be established for each authentication
exchange (request and response).  The KRB_KDC_REP or KRB_ERROR message
will be returned to the client on the same TCP stream that was
established for the request.  The response to a request made through
TCP/IP transport must also use TCP/IP transport. 

Implementors should note that some extensions to the Kerberos protocol
will not work if any implementation not supporting the TCP transport is
involved (client or KDC).  Implementors are strongly urged to support
the TCP transport on both the client and server and are advised that the
current notation of "should" support will likely change in the future to
must support. 

The KDC may close the TCP stream after sending a response, but may leave
the stream open if it expects a followup - in which case it may close
the stream at any time if resource constraints or other factors make it
desirable to do so.  Care must be taken in managing TCP/IP connections
with the KDC to prevent denial of service attacks based on the number of
TCP/IP connections with the KDC that remain open.  If multiple exchanges
with the KDC are needed for certain forms of preauthentication, multiple
TCP connections may be required. 

A client may close the stream after receiving response, and should close
the stream if it does not expect to send followup messages.  The client
must be prepared to have the stream closed by the KDC at anytime, in
which case it must simply connect again when it is ready to send
subsequent messages. 

<P>

The first four octets of the TCP stream used to transmit the request
request will encode in network byte order the length of the request
(KRB_KDC_REQ), and the length will be followed by the request itself.
The response will similarly be preceded by a 4 octet encoding in
network byte order of the length of the KRB_KDC_REP or the KRB_ERROR
message and will be followed by the KRB_KDC_REP or the KRB_ERROR
response.  If the sign bit is set on the integer represented by the
first 4 octets, then the next 4 octets will be read, extending the
length of the field by another 4 octets (less the sign bit of the
additional four octets which is reserved for future expansion and which
at present must be zero).

<H4>8.2.3.  OSI transport</H4>

During authentication of an OSI client to an OSI server, the mutual
authentication of an OSI server to an OSI client, the transfer of
credentials from an OSI client to an OSI server, or during exchange of
private or integrity checked messages, Kerberos protocol messages may
be treated as opaque objects and the type of the authentication
mechanism will be:

<PRE><B>
OBJECT IDENTIFIER ::= {iso (1), org(3), dod(6),internet(1), security(5),kerberosv5(2)} 
</B></PRE>

Depending on the situation, the opaque object will be an
authentication header (KRB_AP_REQ), an authentication reply
(KRB_AP_REP), a safe message (KRB_SAFE), a private message (KRB_PRIV),
or a credentials message (KRB_CRED).  The opaque data contains an
application code as specified in the ASN.1 description for each
message.  The application code may be used by Kerberos to determine
the message type.

<H4>8.2.3.  Name of the TGS</H4>

The principal identifier of the ticket-granting service shall be
composed of three parts: (1) the realm of the KDC issuing the TGS
ticket (2) a two-part name of type NT-SRV-INST, with the first part
"krbtgt" and the second part the name of the realm which will accept
the ticket-granting ticket.  For example, a ticket-granting ticket
issued by the ATHENA.MIT.EDU realm to be used to get tickets from the
ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU"
(realm), ("krbtgt", "ATHENA.MIT.EDU") (name).  A ticket-granting
ticket issued by the ATHENA.MIT.EDU realm to be used to get tickets
from the MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU"
(realm), ("krbtgt", "MIT.EDU") (name).

<H3>8.3.  Protocol constants and associated values</H3>

The following tables list constants used in the protocol and define
their meanings.  Ranges are specified in the "specification" section
that limit the values of constants for which values are defined here.
This allows implementations to make assumptions about the maximum
values that will be received for these constants.  Implementation
receiving values outside the range specified in the "specification"
section may reject the request, but they must recover cleanly.

<PRE>
Encryption type       etype value block size  minimum pad size  confounder size
NULL                           0     1           0                 0
des-cbc-crc                    1     8           4                 8
des-cbc-md4                    2     8           0                 8
des-cbc-md5                    3     8           0                 8
[reserved]                     4
des3-cbc-md5                   5     8           0                 8
[reserved]                     6
des3-cbc-sha1                  7     8           0                 8
dsaWithSHA1-CmsOID             9                                 (pkinit)
md5WithRSAEncryption-CmsOID   10                                 (pkinit)
sha1WithRSAEncryption-CmsOID  11                                 (pkinit)
rc2CBC-EnvOID                 12                                 (pkinit)
rsaEncryption-EnvOID          13                      (pkinit from PKCS#1 v1.5)
rsaES-OAEP-ENV-OID            14                      (pkinit from PKCS#1 v2.0)
des-ede3-cbc-Env-OID          15                                 (pkinit)
des3-cbc-sha1-kd              16                                 (Tom Yu)
rc4-hmac                      23                                 (swift)
rc4-hmac-exp                  24                                 (swift)

[reserved]       0x8003
</PRE>

<PRE>
Checksum type              sumtype value       checksum size
CRC32                      1                   4
rsa-md4                    2                   16
rsa-md4-des                3                   24
des-mac                    4                   16
des-mac-k                  5                   8
rsa-md4-des-k              6                   16 (drop rsa ?)
rsa-md5                    7                   16 (drop rsa ?)
rsa-md5-des                8                   24 (drop rsa ?)
rsa-md5-des3               9                   24 (drop rsa ?)
hmac-sha1-des3-kd          12                  20 
hmac-sha1-des3             13                  20
sha1 (unkeyed)             14                  20
</PRE>

<PRE>
padata and data types           padata-type value  comment

PA-TGS-REQ                      1
PA-ENC-TIMESTAMP                2
PA-PW-SALT                      3
[reserved]                      4
PA-ENC-UNIX-TIME                5                  (depricated)
PA-SANDIA-SECUREID              6
PA-SESAME                       7
PA-OSF-DCE                      8
PA-CYBERSAFE-SECUREID           9
PA-AFS3-SALT                    10
PA-ETYPE-INFO                   11
PA-SAM-CHALLENGE                12                  (sam/otp)
PA-SAM-RESPONSE                 13                  (sam/otp)
PA-PK-AS-REQ                    14                  (pkinit)
PA-PK-AS-REP                    15                  (pkinit)
PA-USE-SPECIFIED-KVNO           20
PA-SAM-REDIRECT                 21                  (sam/otp)
PA-GET-FROM-TYPED-DATA          22                  (embedded in typed data)
TD-PADATA                       22                  (embeds padata)
PA-SAM-ETYPE-INFO               23                  (sam/otp)
TD-PKINIT-CMS-CERTIFICATES      101             CertificateSet from CMS
TD-KRB-PRINCIPAL                102
TD-KRB-REALM                    103
TD-TRUSTED-CERTIFIERS           104
TD-CERTIFICATE-INDEX            105
TD-APP-DEFINED-ERROR            106
</PRE>

<PRE>
authorization data type         ad-type value
AD-IF-RELEVANT                     1
AD-INTENDED-FOR-SERVER             2
AD-INTENDED-FOR-APPLICATION-CLASS  3
AD-KDC-ISSUED                      4  
AD-OR                              5
AD-MANDATORY-TICKET-EXTENSIONS     6
AD-IN-TICKET-EXTENSIONS            7
reserved values                    8-63
OSF-DCE                            64
SESAME                             65
AD-OSF-DCE-PKI-CERTID              66         ([email-masked])
AD-WIN200-PAC                     128         ([email-masked])
</PRE>

<PRE>
Ticket Extension Types

TE-TYPE-NULL                  0      Null ticket extension
TE-TYPE-EXTERNAL-ADATA        1      Integrity protected authorization data
[reserved]                    2      TE-TYPE-PKCROSS-KDC  (I have reservations)
TE-TYPE-PKCROSS-CLIENT        3      PKCROSS cross realm key ticket
TE-TYPE-CYBERSAFE-EXT         4      Assigned to CyberSafe Corp
[reserved]                    5      TE-TYPE-DEST-HOST (I have reservations)
</PRE>

<PRE>
alternate authentication type   method-type value
reserved values                 0-63
ATT-CHALLENGE-RESPONSE          64
</PRE>

<PRE>
transited encoding type         tr-type value
DOMAIN-X500-COMPRESS            1
reserved values                 all others
</PRE>

<PRE>
Label               Value   Meaning or MIT code

pvno                    5   current Kerberos protocol version number
</PRE>

<PRE>
message types

KRB_AS_REQ             10   Request for initial authentication
KRB_AS_REP             11   Response to KRB_AS_REQ request
KRB_TGS_REQ            12   Request for authentication based on TGT
KRB_TGS_REP            13   Response to KRB_TGS_REQ request
KRB_AP_REQ             14   application request to server
KRB_AP_REP             15   Response to KRB_AP_REQ_MUTUAL
KRB_SAFE               20   Safe (checksummed) application message
KRB_PRIV               21   Private (encrypted) application message
KRB_CRED               22   Private (encrypted) message to forward credentials
KRB_ERROR              30   Error response
</PRE>

<PRE>
name types

KRB_NT_UNKNOWN        0  Name type not known
KRB_NT_PRINCIPAL      1  Just the name of the principal as in DCE, or for users
KRB_NT_SRV_INST       2  Service and other unique instance (krbtgt)
KRB_NT_SRV_HST        3  Service with host name as instance (telnet, rcommands)
KRB_NT_SRV_XHST       4  Service with host as remaining components
KRB_NT_UID            5  Unique ID
KRB_NT_X500_PRINCIPAL 6  Encoded X.509 Distingished name [RFC 2253]

</PRE>

<PRE>
error codes

KDC_ERR_NONE                    0   No error
KDC_ERR_NAME_EXP                1   Client's entry in database has expired
KDC_ERR_SERVICE_EXP             2   Server's entry in database has expired
KDC_ERR_BAD_PVNO                3   Requested protocol version number not supported
KDC_ERR_C_OLD_MAST_KVNO         4   Client's key encrypted in old master key
KDC_ERR_S_OLD_MAST_KVNO         5   Server's key encrypted in old master key
KDC_ERR_C_PRINCIPAL_UNKNOWN     6   Client not found in Kerberos database
KDC_ERR_S_PRINCIPAL_UNKNOWN     7   Server not found in Kerberos database
KDC_ERR_PRINCIPAL_NOT_UNIQUE    8   Multiple principal entries in database
KDC_ERR_NULL_KEY                9   The client or server has a null key
KDC_ERR_CANNOT_POSTDATE        10   Ticket not eligible for postdating
KDC_ERR_NEVER_VALID            11   Requested start time is later than end time
KDC_ERR_POLICY                 12   KDC policy rejects request
KDC_ERR_BADOPTION              13   KDC cannot accommodate requested option
KDC_ERR_ETYPE_NOSUPP           14   KDC has no support for encryption type
KDC_ERR_SUMTYPE_NOSUPP         15   KDC has no support for checksum type
KDC_ERR_PADATA_TYPE_NOSUPP     16   KDC has no support for padata type
KDC_ERR_TRTYPE_NOSUPP          17   KDC has no support for transited type
KDC_ERR_CLIENT_REVOKED         18   Clients credentials have been revoked
KDC_ERR_SERVICE_REVOKED        19   Credentials for server have been revoked
KDC_ERR_TGT_REVOKED            20   TGT has been revoked
KDC_ERR_CLIENT_NOTYET          21   Client not yet valid - try again later
KDC_ERR_SERVICE_NOTYET         22   Server not yet valid - try again later
KDC_ERR_KEY_EXPIRED            23   Password has expired - change password to reset
KDC_ERR_PREAUTH_FAILED         24   Pre-authentication information was invalid
KDC_ERR_PREAUTH_REQUIRED       25   Additional pre-authenticationrequired [40]
KDC_ERR_SERVER_NOMATCH         26   Requested server and ticket don't match
KDC_ERR_MUST_USE_USER2USER     27   Server principal valid for user2user only
KDC_ERR_PATH_NOT_ACCPETED      28   KDC Policy rejects transited path
KDC_ERR_SVC_UNAVAILABLE        29   A service is not available
KRB_AP_ERR_BAD_INTEGRITY       31   Integrity check on decrypted field failed
KRB_AP_ERR_TKT_EXPIRED         32   Ticket expired
KRB_AP_ERR_TKT_NYV             33   Ticket not yet valid
KRB_AP_ERR_REPEAT              34   Request is a replay
KRB_AP_ERR_NOT_US              35   The ticket isn't for us
KRB_AP_ERR_BADMATCH            36   Ticket and authenticator don't match
KRB_AP_ERR_SKEW                37   Clock skew too great
KRB_AP_ERR_BADADDR             38   Incorrect net address
KRB_AP_ERR_BADVERSION          39   Protocol version mismatch
KRB_AP_ERR_MSG_TYPE            40   Invalid msg type
KRB_AP_ERR_MODIFIED            41   Message stream modified
KRB_AP_ERR_BADORDER            42   Message out of order
KRB_AP_ERR_BADKEYVER           44   Specified version of key is not available
KRB_AP_ERR_NOKEY               45   Service key not available
KRB_AP_ERR_MUT_FAIL            46   Mutual authentication failed
KRB_AP_ERR_BADDIRECTION        47   Incorrect message direction
KRB_AP_ERR_METHOD              48   Alternative authentication method required
KRB_AP_ERR_BADSEQ              49   Incorrect sequence number in message
KRB_AP_ERR_INAPP_CKSUM         50   Inappropriate type of checksum in message
KRB_AP_PATH_NOT_ACCEPTED       51   Policy rejects transited path
KRB_ERR_RESPONSE_TOO_BIG       52   Response too big for UDP, retry with TCP
KRB_ERR_GENERIC                60   Generic error (description in e-text)
KRB_ERR_FIELD_TOOLONG          61   Field is too long for this implementation
KDC_ERROR_CLIENT_NOT_TRUSTED            62 (pkinit)
KDC_ERROR_KDC_NOT_TRUSTED               63 (pkinit)
KDC_ERROR_INVALID_SIG                   64 (pkinit)
KDC_ERR_KEY_TOO_WEAK                    65 (pkinit)
KDC_ERR_CERTIFICATE_MISMATCH            66 (pkinit)
KRB_AP_ERR_NO_TGT                       67 (user-to-user)
KDC_ERR_WRONG_REALM                     68 (user-to-user)
KRB_AP_ERR_USER_TO_USER_REQUIRED        69 (user-to-user)
KDC_ERR_CANT_VERIFY_CERTIFICATE         70 (pkinit)
KDC_ERR_INVALID_CERTIFICATE             71 (pkinit)
KDC_ERR_REVOKED_CERTIFICATE             72 (pkinit)
KDC_ERR_REVOCATION_STATUS_UNKNOWN       73 (pkinit)
KDC_ERR_REVOCATION_STATUS_UNAVAILABLE   74 (pkinit)
KDC_ERR_CLIENT_NAME_MISMATCH            75 (pkinit)
KDC_ERR_KDC_NAME_MISMATCH               76 (pkinit)
</PRE>
--
Commentary:

Since RFC1510, the definition of the TCP transport for Kerberos
messages was added.

---

From: Ken Raeburn <[email-masked]>
Date: 20 Sep 2000 18:52:38 -0400

> <LI>the Unspecified Address

Should there be similar prohibitions against IPv4 loopback addresses
(127.0.0.0/8)?  Any others?

The current MIT implementation, and I expect all the others, already
implements this, but if we're not going to *allow* the use of the
loopback address when talking to a service on the local host, we
should make it explicit.

> transport must also use UDP/IP transport.

I still think requiring port 88 is stronger than we need, given that
we have no good way of finding a KDC that cannot also be made to
supply a port number.  It prohibits running two independent but
RFC-compliant KDCs on a single host (with one address).

It makes a lot of sense to have a standard port for smtp or finger,
for example, since the typical contact information you start with
includes the hostname and user/list name and nothing else.  But for
Kerberos we start with the realm name, and the means by which we get
to addresses is unspecified.  IMHO selecting the port is in
approximately the same realm as finding the address.

Could we simply say that the assigned and preferred port number is 88,
and when sites distribute their KDC hostname information through
whatever means (distributed text file, SRV records, telepathy), let
them decide whether or not to choose a different port number?

For example:

]] When contacting a Kerberos server (KDC) for a KRB_KDC_REQ request
]] using UDP IP transport, the client shall send a UDP datagram
]] containing only an encoding of the request to the
]] KDC; the KDC will respond with a reply datagram
]] containing only an encoding of the reply message (either a KRB_ERROR
]] or a KRB_KDC_REP) to the sending port at the sender's IP address.
]] Kerberos servers supporting IP transport must accept UDP requests.
]] The response to a request made through UDP/IP
]] transport must also use UDP/IP transport.
]]
]] The IP port number allocated for the Kerberos KDC service is 88 (decimal).
]] Use of port 88 is recommended; however, whatever means are used to
]] locate the KDC (which are outside the scope of this document) may
]] specify alternate or additional port numbers.

Or maybe just leave the last sentence off...

> and clients should support the sending of TCP requests on port 88

See above comments on port numbers.

> TCP/IP transport must also use TCP/IP transport. 

Last sentence looks redundant with the previous; delete it.

> current notation of "should" support will likely change in the future to

Implementors of Kerberos or of applications?  In section 9, TCP
support on the KDC is already a "must".

> which case it must simply connect again when it is ready to send

What kind of "followup"?  Repeated AS_REQ messages with preauth data
or "corrected" principal names?  How about requesting a service ticket
after requesting an inter-realm TGT?  How about requesting a service
ticket after acquiring an initial TGT?

> at present must be zero).

Huh?

What does "less the sign bit" mean?  Only 31 bits are used?  So the
first four-octet value is stripped of its own sign bit and multiplied
by 2**31, giving us a 62-bit unsigned length field?

If the first "sign" bit is simply set to zero, perhaps it should be
called the "high bit" or "bit 31", since it's not being handled as an
indication of sign?

> KRB_NT_X500_PRINCIPAL 6  Encoded X.509 Distingished name [RFC 2253]

This list needs to be consistent with section 7.2.

> error codes

With wide text like some of these, and especially with the bitfield
descriptions in section 5, using <PRE> and then generating plain text
and *then* wrapping long lines, as appears to be done for the .txt
versions of the draft, produces a result that looks lousy.  My
suggestion would be to use HTML tables and make the html->text
conversion worry about the margins for everything.  If the browser
version looks less pretty that way, so be it; IMHO the text version
must be easily readable.

> KDC_ERR_PRINCIPAL_NOT_UNIQUE    8   Multiple principal entries in database

How do these help the application client or server at all?  Shouldn't
a single "database is broken, contact administrator" or "KDC internal
error" entry suffice?

> KRB_AP_ERR_METHOD              48   Alternative authentication method required

What do these mean?

> Since RFC1510, the definition of the TCP transport for Kerberos

And IPv6 addresses.  And new assigned numbers in tables.
And probably more.

Ken

---

From: Ken Raeburn <[email-masked]>
Date: 20 Sep 2000 18:52:38 -0400

For example:

Huh?

What do these mean?

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 21 Sep 2000 12:52:24 -0400

> (127.0.0.0/8)?  Any others?

Perhaps a general admonition, perhaps using SHOULD and/or SHOULD NOT
against allowing addresses which cannot be distinguished from no
addresses (e.g., loopback) as well anything other than unicast
addresses. The reasoning for using SHOULD or SHOULD NOT would be that
there may be some specific exception in the future to the general
rule.

To facilitate the use of Kerberos over local IPC transports a hostname
address class might be useful. I.e., an address type of variable length
whose values would be hostname FQDNs.

Also, the KDC SHOULD be allowed to add/remove addresses from the ticket
addresses list in the client's request at its discretion. This has been
discussed before in the MIT lists. There should be no security risk
involved in allowing the KDC to modify the addresses lists clients
request; in fact, if a principal cannot get forwardable tickets but it
can get tickets with any addresses in asks for, then it can defeat the
restriction of not being allowed to obtain forwardable tickets.

...

> ticket after acquiring an initial TGT?

Subsequent requests on the same TCP connection should not have to be
related to the first request or to each other. Methinks.

...

> Ken

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 21 Sep 2000 12:52:24 -0400

...

...

Nico
--