Re: Document editors

Nicolas Williams wrote:
> 
> There's at least some minor things (e.g., we should move the model of
> channel bindings data from the C-bindings).

I tell you right away that this might be difficult.
Any description at the high level will have to fit every conceivable
language binding or it is misplaced.  Think of programming languages
that you have never heard of before.  I think the channel bindings
are at the correct place where they are, because at the C-Bindings
level they could be discussed in reality.

> 
> And we should clarify the name game issue we were arguing about
> yesterday, particularly considering that rfc1964 implementations have
> been canonicalizing the target_name of GSS_Init_sec_context() forever.

You don't seem to understand.

This canonicalization has always been a local transformation,
and it has been required and performed for both gss_compare_name()
and gss_canonicalize_name() --actually MIT Kerberos did it all
in gss_import_name() IIRC.

So the existing implementation hasn't been a problem.

> 
> Most everything else I do see as either new [optional] optional
> interfaces (GGF extensions, stackable pseudo-mech framework) or new
> mechanisms, BCPs and the channel bindings draft.

Exactly.  All seperate documents, all optional extensions.
No need to change high level or C-bindings for those.

> 
> One thing I think could be added to the base spec (though it might
> require convincing the GGF folk -- note: let's not argue this _now_; I'm
> pointing out how the base spec might change) is the GSS_Store_cred()
> extension, since it fixes a serious gap in the spec.

No no.  GSS_Store_cred() is likely implementation specific, not even
mechanism specific.  Show me how you will implement it with Microsoft
Kerberos.

I remind you that GSS-API addresses also mechanisms that live entirely
in the TCB, and that some TCBs will not give you any kind of control
about credentials.  That really isn't an abstract/portable concept.

I have recently certified a sort of TCB-based gssapi mechanism for
interoperability with our application.  GSS-API v2 with security
context export and import.  Our application loads only a stub
of the mechanism as a shared library.  Exported security context
tokens have a length of 4 bytes.  :)


We've been doing plug-n-play with GSS-API v2 mechanism for 8 years
now, and when I certify a new product, it does not only work in
our most recent software, it will also work in software that
we shipped 6 years ago, honestly.

If GSS-API v2 had real defects I would have fixed them before we
submitted the spec to the IESG, because I knew how much we would
be relying on the quality of the spec for years to come.

And I would sure know now if I had missed something back then!


The normal approach with IETF specs is that they're put together
in a hurry, several people start implementing and during interop
testing the problems of the spec are found and the spec is
updated.

Now GSS-APIv2 is a successor of GSS-APIv1.  Since it had quite
a lot of new features it was not possible to call it GSS-APIv1
and advance it to draft.  Instead, it had to recycle at proposed.

Since I was anticipating that we would never have the time and
resources to do interop&fix-spec cycles, I made sure that the
spec was sufficiently clear and robust on the first shot,
so that interoperability with future implementations would
automatic.  I assure you, this did work out perfectly.
Well until Microsoft started aggressively hacking up Kerberos with
proprietary extensions that are clear violations of existing specs.

W2K Kerberos had a few problems, but these were manageable.
W2K3 is a big mess and a royal PITA when it comes to interoperability
with an installed base of rfc-1964.

Microsoft doesn't realize the problem, because they never really
cared about the name-based authentication of the underlying
Kerberos protocol.  If I hadn't begged for it in W2K beta, they might
not even have implemented a call to query the native names from a Kerberos
authentication.

Access control on Microsoft platforms entirely ignores kerberos principal
names.  ACLs contain binary SIDs, and SIDs can only reliably be mapped
to SamCompatibleName (nt4-accounts, local-accounts and pseudo-accounts
don't have Kerberos Principal names).  One could think of the SIDs
as the canonical names in NT (at least if one ignores the NTLM authentication,
which doesn't use SIDs, but printable NT4-style names).
 
Anyway, none of Microsoft's software really uses the Kerberos principal
names of the underlying Kerberos standards (rfc-1510, rfc-1964) for
anything, they didn't realize and didn't care what a mess they created
and how much they broke or impaired interoperability with their
reckless actions.


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