Re: Document editors

Sam Hartman wrote:
> 
> I was in fact talking about editors for documents to replace RFC 2743
> and RFC 2744.
> 
> I do believe those documents have significant clarity problems and do
> need to be revised.

I violently disagree and I propose that you get your focus on
some real work.  Look at how long it takes to work through the
documents in the Kerberos working group.  There's no point in
wasting time in making an already high-quality spec perfect
when there's so much lag and dissent in the documents that
you're already actively working on.


> 
> Here are some issues I can think of that demonstrate the point:
> 
> 1) I seem to recall you wanting to depricate or at least add text
>    advising against the use of GSS_NT_SRV_HST.  I disagree with this
>    proposal, but it has not yet been discussed.

Nope.

There are two gotchas with the current text about hostbased service names
because the spec suggest to "canonicalize" the hostname part via DNS.

(a) MIT Kerberos has been "canonicalizing" hostbased service name
    via insecure DNS for years and it is probably still doing it.
    (MIT Kerberos tradition is the reason why the spec proposes it...)

(b) normally the local resolver API also uses entries in the local hosts
    file, and it usually even prefers those to actual DNS lookups to
    bridge network failures or times of no network access.
    This might be a security problem, but it also might be a source
    of confusion (I have personally seen tytso experiencing 10 minutes
    of confusion because of a local /etc/hosts entry overriding
    the resolution of a hostname in a hostbased service name).


> 
> 2) Discussion of prot_ready in the Kerberos working group indicated
>    significant lack of clarity on what the spec meant.  We ended up
>    concluding, and I believe that you agreed with our conclusion, that
>    a mechanism may be able to produce prot_ready tokens even if it
>    cannot yet consume them.  The spec is not particularly clear on this point.

This is slightly inaccurate.  The spec is particularly clear that
what functionality is available depends entirely on the gssapi implementation,
and since it doesn't distinguish incoming and outgoing, the prot_ready
flag must apply to both operations (but NOT to both peers!).

What is not clear is how an application should handle it when a gssapi
mechanism has a multi-roundtrip context establishment token exchange,
and provides prot_ready quite early, including message unprotection
and the application uses it.  Recalling unprotected messages from
the application when the context establishement fails is impossible.
Securitywise it would have been my preference to prohibit (or at least
discourage) this possibility in the spec, but my proposal was rejected
by our WG chair John Linn back then.

That change I proposed could be added now without breaking any
installed base, I suppose.  But that is very minor, having that
in the BCP document would be a sufficient interim solution.


> 
> 3) As I mentioned, the discussion of channel bindings is unclear and
>     the way it is presented has been problematic for standards track
>     documents including draft-ietf-krb-wg-gssapi-cfx and
>     draft-ietf-nfsv4-gssapi-ccm.

I remind you that it is hardly used, has been (ab-)used in mechanism
specific ways where used (e.g. Kerberos matching IPv4 channel bindings
against IP-Address restrictions of credentials), and has proven to
cause interoperability problems (FTP GSS-API extensions spec).
The logical step would be to leave ONLY the typed hole (aka function
parameter) add a warning about the known problems and leave
mechanism-, application- or niche-specific uses up to seperate
documents.
 

> 
> 4)  As mentioned previously, I want to revisit GSSAPI naming.

I think this is pointless.  This part of the spec is perfect as it is.

If you want Server-based name translations in a gssapi mechanism
then you MUST implement a server-based name translation functionality
(aka Directory) into your gssapi mechanism as well, which can then be
used by gss_compare_name() and gss_canonicalize_name().

I have the feeling that you cannot accept the fact that Kerberos
lost change control over such dirty hacks as piggy-backing
name translation only on AS and TGS-exchanges instead of
requiring a minimal directory functionality for server-based
name-translations.  That happened during 1992-93 when
Kerberos wizards like Theodore Ts'o, John Linn, Jeff Schiller
and several others made GSS-API v1 an IETF standard (rfc1508/9).

> 
> 5)  The documents should be updated to conform to current standards for
>     RFCs.  They should use the new IP notices (very recent), split
>     normative references, that sort of thing.

That by itself is an extremely poor reason to start editing the document.

rfcs 791,792,793 and many more are significantly older and heavily used,
with your reasoning they should have been obsoleted years ago...


-Martin
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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 protected]