[2969] in Kerberos
Re: a question about kerberos
daemon@ATHENA.MIT.EDU (Wenbo Mao)
Mon Jan 10 10:54:40 1994
From: Wenbo Mao <wenbo@comms.ee.man.ac.uk>
To: bcn@ISI.EDU (Clifford Neuman)
Date: Mon, 10 Jan 1994 15:18:42 +0000 (GMT)
Cc: kerberos@MIT.EDU
In-Reply-To: <9401071655.AA03914@tgo.isi.edu> from "Clifford Neuman" at Jan 7, 94 08:55:39 am
Dear Cliff,
Thank you very much for answering my question and directing the newest
version of the internet document regarding Kerberos.
About the integrity protection for a kerberos ticket, my comment on
the current specification in RFC 1510 is that the specification is
unclear and potentially dangerous. Reasons are given below. First, let
me recite my understanding obtained from the previous versions:
4) the integrity of the ticket is protected by a checksum which is
retrived from the authenticator.
To it your answer is:
> No. The integrity of the ticket is protected by a checksum that is
> encrypted together with the ticket by the long lived secret key from (1).
After carefully checking the RFC 1510, I do find that there is a place
indicating your answer to some conditional extent. This is the
definition of the CipherText (in page 70):
CipherText ::= ENCRYPTED SEQUENCE {
confounder[0] UNTAGGED OCTET STRING(conf_length) OPTIONAL,
check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL,
msg-seq[2] MsgSequence,
pad UNTAGGED OCTET STRING(pad_length) OPTIONAL
}
where the OPTIONAL item check[1] seems to be the mechanism that you
addressed. However, it seems to me that your claim (or the integrity
mechanism used) may not be fully correct if this check is only
OPTIONAL. In contrast, there are many places in the document which
affirmatively specify a different integrity mechanism. Below I copy
these specification parts which concern the integrity and checksum.
In page 6:
The integrity of the messages exchanged between principals can also
be guaranteed using the session key (passed in the ticket and
contained in the credentials). This approach provides detection of
both replay attacks and message stream modification attacks. It is
accomplished by generating and transmitting a collision-proof
checksum (elsewhere called a hash or digest function) of the client's
message, keyed with the session key. Privacy and integrity of the
messages exchanged between principals can be secured by encrypting
the data to be passed using the session key passed in the ticket, and
contained in the credentials.
In page 27:
Once the accompanying ticket has been decrypted, the user-supplied
checksum in the Authenticator must be verified against the contents
of the request, and the message rejected if the checksums do not
match (with an error code of KRB_AP_ERR_MODIFIED) or if the checksum
is not keyed or not collision-proof (with an error code of
KRB_AP_ERR_INAPP_CKSUM).
The points in these two paragraphs are clearer if the data
structures of ticket and authenticator are compared.
In page 42:
5.3.1. Tickets
A ticket is a record that helps a client authenticate to a service.
A Ticket contains the following information:
Ticket ::= [APPLICATION 1] SEQUENCE {
tkt-vno[0] INTEGER,
realm[1] Realm,
sname[2] PrincipalName,
enc-part[3] EncryptedData
}
-- Encrypted part of ticket
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
flags[0] TicketFlags,
key[1] EncryptionKey,
crealm[2] Realm,
cname[3] PrincipalName,
transited[4] TransitedEncoding,
authtime[5] KerberosTime,
starttime[6] KerberosTime OPTIONAL,
endtime[7] KerberosTime,
renew-till[8] KerberosTime OPTIONAL,
caddr[9] HostAddresses OPTIONAL,
authorization-data[10] AuthorizationData OPTIONAL
}
There is no checksum in it. In contrast, there is an OPTIONAL one in
an authenticator (in pages 47-48):
5.3.2. Authenticators
An authenticator is a record sent with a ticket to a server to
certify the client's knowledge of the encryption key in the ticket,
to help the server detect replays, and to help choose a "true session
key" to use with the particular session. The encoding is encrypted
in the ticket's session key shared by the client and the server:
-- Unencrypted authenticator
Authenticator ::= [APPLICATION 2] SEQUENCE {
authenticator-vno[0] INTEGER,
crealm[1] Realm,
cname[2] PrincipalName,
cksum[3] Checksum OPTIONAL,
cusec[4] INTEGER,
ctime[5] KerberosTime,
subkey[6] EncryptionKey OPTIONAL,
seq-number[7] INTEGER OPTIONAL,
authorization-data[8] AuthorizationData OPTIONAL
}
Am I correct to say that this latter mechanism is the integrity
protection that is proposed for the kerberos proper since the
definition of CipherText in page 70 is not a part of the Kerberos and
hence is optional? If so, we may see the following scenario: the
ckecksum which supposes to protect the integrity of a key is protected
by the key.
May be I have missed something. I would be grateful for your pointing
them out for me.
Kindest regards,
Wenbo
