Subject: new KRB-SAFE/KRB-PRIV messages

From: Tom Yu <[email-masked]>
Date: 04 Dec 2000 15:57:06 -0500

The revisions as they currently stand change the KRB-SAFE and
KRB-PRIV messages to premit the omission of the sender address.  This
creates a backwards compatibility problem.  As I indicated in my
previous comments on section 5 of kerberos-revisions, there should be
new types defined, probably as follows:

    KRB-SAFE-2 ::= [APPLICATION 18] SEQUENCE {
            pvno            [0] INTEGER,
            msg-type        [1] INTEGER,
            safe-body       [2] KRB-SAFE-BODY-2 OPTIONAL,
            cksum           [3] CHecksum
    }

    KRB-SAFE-BODY-2 ::= SEQUENCE {
            user-data       [0] OCTET STRING,
            timestamp       [1] KerberosTime OPTIONAL,
            usec            [2] INTEGER OPTIONAL,
            seq-number      [3] INGETER OPTIONAL,
            s-address       [4] HostAddress OPTIONAL,
            r-address       [5] HostAddress OPTIONAL
    }

    KRB-PRIV-2 ::= [APPLICATION 19] SEQUENCE {
            pvno            [0] INTEGER,
            msg-type        [1] INTEGER,
            enc-part        [3] EncryptedData -- encrypted EncKrbPrivPart2
    }

    EncKrbPrivPart2 ::= [APPLICATION 24] SEQUENCE {
            user-data       [0] OCTET STRING,
            timestamp       [1] KerberosTime OPTIONAL,
            usec            [2] INTEGER OPTIONAL,
            seq-number      [3] INTEGER OPTIONAL,
            s-address       [4] HostAddress OPTIONAL,
            r-address       [5] Hostaddress OPTIONAL
    }

The reason to make the safe-body field of KRB-SAFE-2 optional is to
allow for an application to encode a KRB-SAFE-BODY-2 but not transmit
it.  This is a Kerberos protocol equivalent of a GSSAPI MIC token,
which would make the definition of a GSSAPI mechanism based almost
entirely on Kerberos messages possible.

This numbering of the tag numbers is chosen to keep the functional
blocks of tag numbers contiguous.  The only way to extend the block of
tag numbers associated with "encparts" (25..29) is backwards;
extending that block forwards would collide with [APPLICATION 30],
which is KRB-ERROR.  Likewise, the block of tag numbers associated
with "application messages" (20..22) is extended backwards to avoid
conflict with the "encpart" tag number space.

Incidentally, we may want to rethink the numbering of the TGT-REQ and
TGT-REP (if we want to have a TGT-REP one as opposed to sending a raw
ticket) messages in the light of the directions we need to extend the
application protcol messages for KRB-SAFE and KRB-PRIV.  Also,
somewhat arguably, a TGT-REQ is part of an application protocol, not a
core authentication message.

Backwards compatitility problems are then solved by making it the
application protocol designer's choice whether to use the new messages
in a new revision of the protocol, rather than retroactively modifying
existing protocols by redefining Kerberos message types.

Are there any objections to this concept for creating new types for
KRB-SAFE and KRB-PRIV?

---Tom

---

From: Ken Raeburn <[email-masked]>
Date: 04 Dec 2000 16:11:39 -0500

> entirely on Kerberos messages possible.

Might we want to use any of the other fields of KRB-SAFE-BODY-2 (most
likely the sequence number, but perhaps the timestamp) in a MIC token?
If so, then the user-data, not the safe-body, should be the OPTIONAL
field.

---

From: Tom Yu <[email-masked]>
Date: 04 Dec 2000 16:29:44 -0500

>>>>> "raeburn" == Ken Raeburn <[email-masked]> writes:

raeburn> Might we want to use any of the other fields of
raeburn> KRB-SAFE-BODY-2 (most likely the sequence number, but perhaps
raeburn> the timestamp) in a MIC token?  If so, then the user-data,
raeburn> not the safe-body, should be the OPTIONAL field.

Oh.  Now that I think about it, you're right.  That would make all
components of a KRB-SAFE-BODY-2 optional, and an application (or
GSSAPI mechanism) wanting to send a MIC token or equivalent would have
to encode the KRB-SAFE-BODY-2 twice: once with the user-data, and once
without.

This does bring up the problem of re-encoding, since an application
would likely decode the KRB-SAFE-BODY-2 and re-encode it with the
user-data field present, which could cause problems with things such
as the usec field, for instance.  A careful implementation could
probably get around that, though, by keeping track of whether certain
fields were actually encoded.

---Tom