Subject: Concerns about Kerberos-Revisions

From: Sam Hartman <[email-masked]>
Date: Sun, 6 Dec 1998 14:30:30 -0500 (EST)

It's great to see a new version of revisions out.  I think we
       are fairly close, but I do have a few concerns:

1) Revisions makes the addresses in the krb-priv and krb-safe messages
optional.  I was one of the major proponents for this at MIT, and I
certainly still believe that it is important for Kerberos to be able
to run in environments where proxies or address translation are being
used.  However, I had not previously noticed that in addition to
providing fairly insecure authentication, the addresses did provide
protection against reflection attacks (a message generated by A is
replayed to A) in many situations.

Have we considered defining a special address type that designates a
party's role in a communications exchange to protect against
reflection.  For example, in the case where you have two parties, one
sending krb-app-req and one sending krb-app-rep, the party sending
app-req could canonically be labeled 0 and the other labeled 1.  If
so, why was this rejected; if not, we should consider this and other
solutions to the reflection problem.

Also, while I'm on the topic of addresses, I remember seeing a draft
on Kerberos usage in an IPV6 environment a while back which defined
the IPV6 address type.  Would it be a good idea to fold this into
Revisions?

2) According to section 5.3, the authorization data elements in
appendix B should be understood by all applications; since that is a
should, not a must, then it is not required for applications to
understand these elements.  One good reason for not understanding
these elements would be pre-existing applications that have not yet
been updated.  However appendix b specifies behavior (especially in
ad-and-or) for what an application must do if it does not implement
the option.  Unfortunately, no where in RFC 1510 nor in Revisions can
I find text that mandates application servers reject tickets
containing not-understood authorization data.  I argue:

    a) It is unreasonable to mandate that an application MUST do
something with a particular option it does not implement, while other
applications that do not understand the option MAY ignore it.  Since a
client does not have a way of distinguishing applications that
recognize but do not implement from those that do not recognize, then
no client can depend on the application taking the mandatory action.
Thus, there is no increased security or interoperability, and so I do
not see the justification for MUST.  

    b) It would be possible to change the should in section 5.3 to a
MUST, requiring all applications to recognize the ad-elements in
appendix b.  I do not think that a change that makes all existing
Kerberos applications incompliant with the specification is justified
at this point in the Kerberos protocol's evolution.

 3) I'm afraid that Tom's concerns about ASN.1 extensibility probably
shouldn't be limited to ticket extensions.  Certainly, my agreement
that adding the checksum and e-type-data fields to KRB-ERROR messages
was based on the assumption that it was reasonable to extend ASN.1
sequences.  Tom's argument was fairly convincing, so I think we may
wish to re-evaluate whether adding any fields to commonly-used
sequences would be a good idea at this time.  I certainly agree with
the text that requires additional fields not to be dropped from
sequences, but until existing implementations actually implement this
text, I do not believe taking advantage of it is wise.

--Sam
==========================================================================
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]