Subject: Re: Section 5 Kerberos Revisions for comment

From: Ken Raeburn <[email-masked]>
Date: 02 Oct 2000 17:04:24 -0400

Tom Yu <[email-masked]> writes:
> Ken Raeburn points out that there might be a useful semantic meaning
> to sending an empty HostAddresses list... that being that no addresses
> are ever valid for a ticket, for example, as opposed to the case where
> there is no HostAddresses list sent at all, which would indicate that
> any addreses are permitted.

A clarification: While tickets valid from no addresses would seem to
make no sense in the Kerberos protocol, it might be reasonable in some
cases (variants on the IAKERB proposal, for example) to want to send a
"Kerberos-like" message that will be modified before going to the KDC.
For example, sending a AS_REQ to an IAKERBish proxy with the address
field omitted could all addresses, while including a possibly-empty
field means the proxy can add the IP address that will be assigned to
the client.

We could still take the stricter approach and say that such messages
simply aren't Kerberos messages and therefore we don't care about
making room for them in the protocol spec.  (And if implementations
want to be lax and allow such uses, that's up to them.)

> Like other uses of SEQUENCE OF types, this should probably be:
> 
>     LastReq ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE {
>         lr-type     [0] INTEGER,
>         lr-value    [1] KerberosTime
>     }

Tom and I talked about this on Friday.  The one use of this field (in
KDC-REP) is not OPTIONAL, and there may be no information to convey,
so allowing zero elements may be reasonable.  Then again, do current
implementations allow zero elements?  We probably still shouldn't get
rid of lr-type zero meaning "no information", even though it still
requires parsing a useless time value if the ASN.1 parsing code
doesn't understand the semantics.

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

If we allow user-data in KRB-SAFE-BODY-NEW to be OPTIONAL, and
indicate that user-supplied data will be checksummed even if not
included in the message, suddenly we have the Kerberos equivalent of
the GSSAPI MIC token.

> bcn> <H4>5.7.1.  KRB_PRIV definition</H4>
> 
> bcn> The KRB_PRIV message contains user  data  encrypted  in
> bcn> the Session Key.  The message fields are:
> 
> bcn> KRB-PRIV ::=         [APPLICATION 21] SEQUENCE {
> bcn>                      pvno[0]                           INTEGER,
> bcn>                      msg-type[1]                       INTEGER,
> bcn>                      enc-part[3]                       EncryptedData
> bcn>                                                        -- EncKrbPrivPart
> bcn> }

Regarding backwards compatibility issues, it should be noted that
RFC1510 allowed the application to supply the initialization vector
used when encrypting enc-part, and suggested that the last bytes of
the previous KRB-PRIV's enc-part could be used.  This probably wasn't
a great idea in retrospect, and I don't know of any applications
actually supplying the ivec, but the removal of that option should be
noted.

> In any case, if we decide to make new types with different
> application tag numbers, we need to pick these numbers... hopefully
> all less than 31, since that starts running us into the area where we
> will need more than one byte to encode the identifier octets in the
> encoding.

Perhaps we should have a list someplace of all the application tags
used in the current spec.

Ken

---

From: Sam Hartman <[email-masked]>
Date: 05 Oct 2000 08:55:52 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> I think this is meant for Appendix B; similarly with
    Nicolas> ticket extension types. Looking at version 6 of the
    Nicolas> draft, I would like to talk about adding serveral
    Nicolas> authorization and extension data types.

Is now really the time to be discussing adding new things to Kerberos?
It seems like we are having a hard enough time agreeing on the
protocol as it already sort of exists.  I think that perhaps such
discussion should wait until after kerberos-revisions is done.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Oct 2000 12:14:09 -0400

I will propose what I think is the least necessary to provide a suitable
replacement to the MS PAC thing:

 - an authorization data type for specifying a client principal's other
   names, e.g., usernames, LDAP DNs, etc...

 - an authorization data type to provide additional signatures of the
   rest of the ticket. I.e., a checksum of the rest of the ticket
   encrypted in the key of a named principal

I'll try to send the ASN.1 definitions and text suitable for a draft
today.

Nico

--