RFC1510-REVISION

Assar Westerlund <assar@sics.se> Tue, 15 April 1997 02:56 UTC

Received: from cnri by ietf.org id aa15071; 14 Apr 97 22:56 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa26398; 14 Apr 97 22:56 EDT
Received: (daemon@localhost) by pad-thai.cam.ov.com (8.8.5/) id <BAA09753@pad-thai.cam.ov.com>; Tue, 15 Apr 1997 01:08:14 GMT
To: Clifford Neuman <bcn@isi.edu>
Cc: cat-ietf@mit.edu
Subject: RFC1510-REVISION
References: <199704112003.AA03004@cayman-islands.isi.edu>
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset="US-ASCII"
From: Assar Westerlund <assar@sics.se>
Date: Tue, 15 Apr 1997 03:08:23 +0200
In-Reply-To: Clifford Neuman's message of Fri, 11 Apr 1997 13:03:37 -0700
Message-Id: <5l208dgkjc.fsf@assaris.sics.se>
Lines: 60
X-Mailer: Gnus v5.2.40/Emacs 19.34
Precedence: bulk

Clifford Neuman <bcn@ISI.EDU> writes:
>   http://gost.isi.edu/info/kerberos/1510revision.txt 

I have some comments.

> O Requirements on the length of bitstrings for options and tickets
>   have been specified.  These fields should be generated as multiples
>   of 32 bits and have a minimum length of 32 bits.

(5.2)

Why should this restriction be incorporated?  Given that the
specification is using ASN.1/DER, why not follow it?

> O Words have been added regarding TCP support for messages to and
>   from the KDC.

(8.2.1)

What about specifying that the client should close its side of the TCP
connection (with i.e. shutdown) to signal that the packet has ended.
It makes life easier for the KDC and the client is anyway not going to
send more data.

> O A possibly controversial example of subkey negotiation has been added.

(3.2.6)

I don't think there's any good reason for including this example.  I'm
not sure what it clarifies and we shall not try to endorse any kind of
broken cryptography.

> O We should decide on wording regarding a recommendation for support of
>   the TCP transport as an option.

I suggest:

"Servers SHOULD also accept TCP requests on port 88 (decimal)."

> O We need to decide how to deal with a few checksum methods that were
>   implemented incorrectly, and how to update the spec to reflect
>   actual practice, or otherwise transition to consistency between the
>   spec and implementations.

Which are those incorrectly implemented methods?

I think it would be useful to add, in addition to the required
encryption/checksum methods, a list of ``recommended'' methods.  And
perhaps a wording of something like this ``you SHOULD only generate
data with these methods, but MUST recognize the list mentioned in
9.1''?

O Should we not add a type for IPv6 addresses in 8.1?  There's not any
value for `AF_INET6' in draft-ietf-ipngwg-bsd-api-07.txt so I guess we
will have to come up with a value on our own.

O I hope you have updated the OID to be `iso(1), org(3), dod(6),
internet(1), security(6), kerberosv5(2)'.

/assar