Subject: application tag numbers, new types for u2u, etc.

From: Tom Yu <[email-masked]>
Date: 27 Nov 2000 22:19:39 -0500

So I was looking over Section 5 of kerberos-revisions, and it occurs
to me that a listing of the application tag numbers used in the ASN.1
syntax for Kerberos would be a good idea.  It may be a good idea to
include these in an appendix somewhere.  In addition, a few ideas
(some related to user-to-user things) occured to me regarding the
assignment of tag numbers.  To start with, I have listed the
application tag numbers below:

--------------------

 1    Ticket
 2    Authenticator
 3    EncTicketPart

10    AS-REQ
11    AS-REP
12    TGS-REQ
13    TGS-REP
14    AP-REQ
15    AP-REP

20    KRB-SAFE
21    KRB-PRIV
22    KRB-CRED

25    EncASRepPart
26    EncTGSRepPart
27    EncAPRepPart
28    EncKrbPrivPart
29    EncKrbCredPart

30    KRB-ERROR

--------------------

In order to ensure that the DER encoding of the tag does not exceed
one byte, the tag number must be less than 31.  This is the result of
the use of other bits within this byte to designate the tag class and
construction.  This means that the following tag numbers remain open
for assignment: { 4..9, 16..19, 22..24 }, for a total of 13 unassigned
tag numbers.

There appears to be some vague functional grouping of application tag
numbers; the main PDUs relating to establishing authentication use tag
numbers from 10..15; the PDUs sent as parts of application protocols
use tag numbers from 20..22; the encrypted parts of PDUs get tag
numbers 25..29; KRB-ERROR gets the oddball tag number of 30; and the
commonly used (non-PDU) types Ticket, Authenticator, and EncTicketPart
get tags 1..3.

For new types, we may wish to assign tag numbers in accordance with
this apparent pre-existent functional grouping scheme of tag
numbering.

Additional types that may be useful to add to the protocol include new
versions of the Ticket, KRB-SAFE, and KRB-PRIV types that will exist
to prevent backwards-compatibility problems.  Also, there are new PDUs
that are useful in the context of user-to-user authentication.

For example, the (now expired) draft-swift-win2k-krb-user2user-00.txt
has:

    KERB-TGT-REQUEST ::= SEQUENCE {
	    pvno[0]         INTEGER,
	    msg-type[1]     INTEGER,
	    server-name[2]  PrincipalName OPTIONAL,
	    realm[3]        Realm OPTIONAL
    }

and lists the msg-type as 16.  I propose modifying this somewhat, to
arrive at:

    TGT-REQ ::= [APPLICATION 16] SEQUENCE {
	    pvno            [0] INTEGER,
	    msg-type        [1] INTEGER,
	    sprinc          [2] PrincipalName OPTIONAL,
	    srealm          [3] Realm OPTIONAL
    }

which allows more sane error-checking by the parser, since it can bail
out immediately upon failing to match the tag number.

Likewise, the proposed KERB-TGT-REPLY, which is:

    KERB-TGT-REPLY ::= SEQUENCE {
	    pvno[0]         INTEGER,
	    msg-type[1]     INTEGER,
	    ticket[2]       Ticket
    }

which has msg-type=17, is probably best rewritten as:

    TGT-REP ::= [APPLICATION 17] SEQUENCE {
	    pvno            [0] INTEGER,
	    msg-type        [1] INTEGER,
            sprinc          [2] PrincipalName OPTIONAL,
            srealm          [3] Realm OPTIONAL,
	    ticket          [4] Ticket
    }

for reasons similar to that listed above for TGT-REQ.  The additional
fields sprinc and srealm are so that the requestor of the ticket can
omit them on the request, and have the server give whatever ticket is
available.  The cleartext portions of a ticket as defined in protocol
as it stands now contain the server name, but not the client name.  In
the case of user-to-user authentication, the "server" name in the
cleartext part of the ticket returned by the u2u server to the u2u
client is almost always of the form "krbtgt/REALM@REALM", which isn't
terribly useful to the client.  The u2u client really should get the
"client principal name" of the TGT that the u2u server returns, which
is in the encrypted portion of the ticket, and thus normally
inaccessible.

The messages that a u2u client would use to request and receive a TGT
from a u2u server are useful in contexts outside of GSSAPI, in the
case that an application protocol not based on GSSAPI wishes to do
user-to-user authentication.  The use of application-class tags for
these messages facilitates error-checking in the case where such a
non-GSSAPI application protocol uses user-to-user authentication and
may not have its own framing for such messages.  Admittedly, they do
bloat the encoding some due to being "explicit" tags, but not nearly
as much as all the explicit context-specific tags (like [0], etc.)
elsewhere, which I've retained for the dubious purpose of conforming
with existing style.

---Tom

---

From: Jonathan Trostle <[email-masked]>
Date: Tue, 28 Nov 2000 08:25:08 -0800

See below:

>application tag numbers below:

If such fields were added, then they should be called the client name and client realm, since that's what they are in the ticket. I'd like to see the scenario that shows why adding these fields would be useful. In particular, the requester cannot trust these fields (since they are unprotected).

Jonathan

---

From: Tom Yu <[email-masked]>
Date: 28 Nov 2000 20:05:31 -0500

>>>>> "jtrostle" == Jonathan Trostle <[email-masked]> writes:

jtrostle> If such fields were added, then they should be called the
jtrostle> client name and client realm, since that's what they are in
jtrostle> the ticket. I'd like to see the scenario that shows why
jtrostle> adding these fields would be useful. In particular, the
jtrostle> requester cannot trust these fields (since they are
jtrostle> unprotected).

The basis for the naming of the fields is that from the perspective of
the u2u client, the fields returned in the TGT-REP would be the
"server" principal name/realm.  This is in spite of the names
corresponding to the "client" as encoded in the encrypted part of the
TGT being returned.  This confusion regarding which is the "client"
and which is the "server" is almost guaranteed when talking about
user-to-user authentication...

I was going to say that the added fields are necessary in the case
where the client doesn't know the server principal name and needs to
learn it in order to construct a correct TGS-REQ.  It turns out that
based on a closer reading, a TGS-REQ may omit the server
principal/realm in the case where additional tickets are provided.

You are correct in noting that the u2u client should not trust the
"server name" returned, but it should probably also be pointed out
that if the client does not know the server's principal name/realm and
relies on the TGS-REP to obtain it, the returned value in the TGS-REP
should be checked against some ACL or other on the client side, to
avoid authenticating or sending sensitive information to an untrusted
service.  Perhaps there should be some GSSAPI nametype support for
authenticating to "one of a set of principals", but that could be
difficult.

So yes, it would be possible to omit the proposed "sname" and "sprinc"
fields from TGT-REP.  Of course, this results in much needless
redundancy wrapped around a Ticket encoding, which can be obviated by
simply sending the raw Ticket back to the client and avoiding
altogether defining a new message type, since a Ticket has its own
application tag number to facilitate easy checking.  Sending a raw
Ticket as a reply to a TGT-REQ does mean that a Ticket now becomes a
PDU, which may or may not merit additional discussion.

---Tom