Subject: converting from ticket1 to ticket2

From: [email-masked] (Sam hartman)
Date: Thu, 10 Jan 2002 14:10:06 -0500 (EST)

I'm beginning to follow up on issues I discussed before the IETF and
at the meeting .

One of the open issues in extensibility 3 and 3a  was what to do about
situations where  you have a ticket2 and  want a ticket1.  This comes
up if you have multiple implementations  on the same client or if you
need to present a ticket to a u2u server.  

Nico proposed that  we treat clients the same as servers, requiring
that  they only send As-REQ2 when they know they will never need
ticket1s for any of these purposes.    When document authors  and I met
Sunday  of IETF week,  we felt that this would be too restrictive.

We propose to include a KDC-REQ flag to request that a ticket1 be
returned.  This will require modifications to the message format rules
presented in extensibility 4 and to the ASN.1 module to reserve the
flag.  If this flag is set, then a ticket1 must be returned, otherwise
the rules currently outlined will be followed.

Marc Horowitz pointed out that in the case where no ticket extensions
are used and no ASN.1 extensibility are used, there is no harm in
downgrading a ticket2 to a ticket1 on the client.  Currently we have a
flag in the ticket2's encrypted part that lets the server know whether
it should have expected a ticket1 or a ticket2.  Marc proposes to
relax the definition of this flag so that is set only in cases where
allowing a dowgrade would lose information.  We  believe that
supporting Marc's proposal  is reasonable, although requiring clients
to implement it is not.  Thus, we propose to relax the definition of
the ticket flag to be set only when  the ticket MUST be signed; the
flag should not be set in the cases where  no  extensions are used.  A
client can decode a ticket2 and reencode a ticket1 provided that no
extensions are used in the ticket2.

--Sam