transited encoding
Tom Yu
tlyu at MIT.EDU
Wed Jul 31 01:18:39 EDT 2013
Frank Cusack <frank at linetwo.net> writes:
> RFC 4120, section 5.3 and Appendix A indicate that in a ticket
> (EncTicketPart) the 'transited' field is mandatory.
>
> I can find no description of how the AS adds or does not add the name of
> its own realm.
>
> However, 3.3.3.2 says that the TGS takes the existing transited field (from
> the TGT) and possibly adds the TGT issuer's realm, before encoding a new
> transited field into the issued ticket. It doesn't say anything about
> stripping or not stripping the local realm, but it is explicit that local
> realm authentication results in "a transited field that is empty".
3.3.3.2 seems clear that the client's realm and the KDC's realm are
not in the transited field.
> 1) Is this the same for a TGT?
For a TGT obtained via the AS, I believe this is also true.
(Typically, it's not possible to use the AS to get a cross-realm
ticket.)
> 2) How does one encode an empty but required ASN.1 TransitedEncoding
> Sequence? Would this be a sequence of length 0? What exactly does that
> look like?
I think it's reasonable to interpret the text that refers to an empty
TransitedEncoding as meaning that the "contents" OCTET STRING field in
the TransitedEncoding is empty. An ASN.1 SEQUENCE type can't be empty
unless it's defined with no contained types. An ASN.1 SEQUENCE OF
type can be empty unless it's constrained to be non-empty; this is a
problem for producing canonical ASN.1 values for types where there is
a SEQUENCE OF type contained as an OPTIONAL member of another type.
(i.e., do you encode a zero-length SEQUENCE OF value, or omit it
entirely?)
More information about the Kerberos
mailing list