[1515] in Kerberos
IMPORTANT: Changes to naming and encryption in Kerberos V5
daemon@ATHENA.MIT.EDU (Clifford Neuman)
Fri Aug 16 15:30:19 1991
Date: Fri, 16 Aug 91 12:21:24 -0700
From: bcn@cs.washington.edu (Clifford Neuman)
To: krb-protocol@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU
I have not heard any objections to the proposed changes sent to the
krb-protocol list, so as stated in my previous message (to krb-protocol),
the following should be considered changed/added in Kerberos V5. More
details are included in the original message. These changes will be
incorporated into the spec:
Rules for assignment of realm names:
4 Styles: domain, X.500, other, none-of-the-above
domain: host.subdomain.domain (example)
X500: C=US/O=OSF (example)
other: NAMETYPE:rest/of.name=without-restrictions (example)
none-of-the-above: reserved, but will not conflict with above
All values for NAMETYPE are also reserved.
For domain names and X.500 names, the realm must be either assigned in
the naming system to the organization, or the realm name must be
derived from the name of a parent realm which recursively satisfies
this requirement.
A new name type field will be part of the principal name:
PrincipalName ::= SEQUENCE {
name-type[0]
SEQUENCE OF GeneralString
}
The following name types are defined:
name-type value meaning
NT-UNKNOWN 0 Name type not known
NT-PRINCIPAL 1 Just the name of the principal as in DCE, or for users
NT-SRV-INST 2 Service and other unique instance (krbtgt)
NT-SRV-HST 3 Service with host name as instance (telnet, rcommands)
NT-SRV-XHST 4 Service with host as remaining components
NT-UID 5 Unique ID
For now, these should be treated as hints. Ignoring the name type, no
two names can be the same (i.e. at least one of the components, or
the realm, must be different). At some point in the future this might
change, so people should at least think about how they would deal with it.
Changes to encryption and checksum mechanisms:
Initialization vectors for all DES encryption will be changed to 0. Note
that as already described in the existing spec, the first block of the
plaintext is always a random confounder and the second includes a
checksum over the confounder and other fields.
New encryption types des-cbc-md4 and des-cbc-md5 will be added
All implementations will have to support des-cbc-md5 in addition to
des-cbc-crc.
The requirement to add des-cbc-md5 as a required encryption method
results from a potential vulnerability of the des-cbc-crc method to
certain chosen plaintext attacks.
~ Cliff
