Subject: RE: CAT-WG Last-Call: pk-init-07 and pk-cross-05

From: "Linn, John" <[email-masked]>
Date: Mon, 16 Nov 1998 13:33:28 -0500

I'll open the discussion with a pair of related questions: 

- do these drafts have known dependencies on changes which
kerberos-revisions makes relative to RFC-1510, and/or 

- do any anticipated modifications to be made in kerberos-revisions impact
these drafts?

--jl

> ----------
> From: 	Linn, John
> Sent: 	Monday, November 16, 1998 1:13 PM
> To: 	'CAT-WG List'
> Subject: 	CAT-WG Last-Call: pk-init-07 and pk-cross-05
> 
> This message is to open a CAT-WG Last-Call, to extend through Wednesday, 2
> December, on the recently resubmitted pk-init-07 and pk-cross-05
> Internet-Drafts as potential candidates for WG recommendation to become
> Proposed Standards.  WG discussion at the Chicago meeting specifically
> anticipated a WG Last-Call on pk-init, following changes which have been
> incorporated into the -07 version.  WG Last-Call for pk-cross was not
> specifically discussed at the Chicago meeting.  My understanding, however,
> is that no changes are currently pending or planned for pk-cross, and that
> its advancement consideration is pending on pk-init, on which it depends;
> in the interests of efficiency, therefore, I'll propose that both
> documents be considered within the same WG Last-Call.  If there's
> objection to this approach, please make it known to the list for
> discussion and we can consider narrowing this WG Last-Call to pk-init
> alone.
> 
> --jl
> 
> 
> 
> 
==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Tom Yu <[email-masked]>
Date: Mon, 16 Nov 1998 19:06:23 -0500

Ok... right off, I must object to pk-cross going to Proposed Standard
due to its usage of the TicketExtension field that is proposed in
kerberos-revisions.  At least one implementation (MIT's) of Kerberos
will signal an error if it receives the proposed TicketExtension
field.

The problem is that the ASN.1 syntax for a protocol defines the
complete extent of the protocol, both from my interpretation and by
implication in the language in Amendment 1 to ISO 8824-1.  Adding an
additional field to an ASN.1 SequenceType, which the proposed
TicketExtension does, creates a logically different type unless the
extensibility amendment has been invoked.  Arguably, if the original
RFC 1510 had specified that implementations shall receive extra fields
in ASN.1 SequenceType values without error and preserve them when
re-encoding the values, the implementations would not have been
allowed to reject such tickets.

This problem is probably the reason that Amendment 1 to ISO 8824-1 was
issued.  It defines extensibility semantics for types such as the
ASN.1 SequenceType, which would allow for such extensibility of a
protocol.  Unfortunately, the amendment was not issued until 1996,
which means that Kerberos could not have taken advantage of such
notation when the original RFC 1510 was written.  The authors of RFC
1510 failed to specify that an implementation should accept and
re-encode extra fields in SequenceType values, which was perhaps a
mistake, though it is an understandable one.

Even when using extensibility in a protocol syntax, it is up to the
application designer to specify whether an implementation that
understands only the base type is required to store and re-encode
extension fields when it receives them from a newer implementation
that encodes an extended type.  Of course, if we were re-writing the
Kerberos ASN.1 syntax today, we would add that requirement in.

Sam Hartman has come up with an alternative to using the proposed
TicketExtension field.  I'll let him elaborate on it, as I do not
recall the particulars at the moment.

---Tom

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Thu, 19 Nov 1998 15:22:09 -0500

To amplify on Tom's comments, the MIT 1.0 release of Kerberos, upon
which a number of commercial implementations are based, will choke if
they receive an unexpected member in the ASN.1 sequence which they
weren't expecting --- for example, the TicketExtensions field.  

I didn't think this was the case, but it turns out we were wrong, and a
bug prevented it from properly skipping over the unknown field.  (In no
case would it have retransmitted it when re-encoding the ticket,
however, so it's not clear that pk-cross would have worked with 1.0
implementations even without this bug.)  This bug has been fixed in our
sources, so the 1.1 release will ignore unknown ASN.1 elements in the
sequence.  (This was something we only recently discovered, or I would
have warned Cliff about this earlier.)

However, as Tom points out, the ASN.1 standard doesn't allow extensions
to sequences; or rather, it makes no guarantees what an implementation
will do if it sees an extended sequence element, since tehcnically it's
a different type.  So while it's a "bug" in the sense that the code
didn't do what we intended it to, the fact that the 1.0 release choked
on unknown fields doesn't make it non-compliant with RFC-1510, since
1510 didn't have this field, and a legitmate 1510 implementation doesn't
need to be able to deal with extended fields.

This makes me believe that we need to seriously rethink the ticket
extensions field in the kerberos-revisions draft, as it has some rather
serious interoperability problems.  And since pk-cross depends on ticket
extensions, I think we need to hold advancement until we settle this
first issue.

					- Ted