Re: Document editors

Douglas E. Engert wrote:
> 
> I thing it would be important to have the WG members and editors who 
> have dealt with multiple GSSAPI implementations. The extensions 
> need to address the needs of more then just Kerberos.

violent agreement.

> 
> We need to strive to provide the generic hooks so calls to mech specific
> routines can be made via the GSSAPI and not be calling the underlying 
> mechanisms routines directly. I believe that this is one of the traps a 
> mechanism developer can fall into as they only have to deal with their
> own mechanism, and this has lead to applications being tied to
> specific mechs or even specific implementations of a mech. 


I don't think it is as easy as that.
You seem to underestimate the width of the scope and the level
of abstraction of the GSS-API spec.

There's nothing wrong with trying to create a model that can be used
with several gss-api mechanisms within your framework.  But you should
be aware that it is impossible to do any kind of that stuff with
the level of abstraction that the GSS-API high level spec would
require to make it part of the base spec.

Why do so many here have a problem with creating a document for an optional
extension for GSS-API?

DCE has gss-api extensions (it needs it for authorization stuff),
and so does SESAME.  Both of these are middlewares that provide
POSIX-style access control, and both of them absolutely require
authorization extensions.  Even Microsoft requires such extensions.

SESAME hat their extensions submitted to the IETF, but nobody
was interested to work on it.  There was another proposal
during 1997/98 (Generic Authorization Extensions), the last
draft (draft-ietf-cat-gaa-cbind-05.txt) expired April 2001,
and CAT didn't catch on.

Many authentication systems don't come with Authorization
features -- only the middleware infrastructures like
DCE, SESAME and Microsoft Domains have it, and maybe there
are some home-brew concoctions using central server/repository
(maybe even LDAP) for their access control mappings.
But other than that, the majority of authentication system is
just that, an authentication system. (Just wondering: are
there any kind of SASL-extensions supporting authorization,
or is it all either black magic (e.g. Microsoft impersonation)
or plain authentication?
 

Now if you think that you can come up with an abstract spec
for moving around (delegated) credentials, then here's a little
work for you:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/constdel.mspx

This URL links to a description of a new feature in Windows 2003.
Besides the regular delegation it also describes an awkward new
possibility to forge Service tickets impersonating arbitrary
not-present users (with the option to limit the services for which
service tickets can be forged).  TGT-less delegation and forged
forwardable service tickets--that's the first time I see this.


If you come up with an abstract spec which I could then implement
in gsskrb5.dll to map to this "fancy new feature", then we might
have a level of abstraction that might be worth discussing.
(btw. I don't like that new W2K3 feature, it actually sounds like
 a big security hole to me).

However we should still go for a seperate extension document,
since there are whole classes of gssapi mechanism where such
kind of fiddling with credentials is architecturally impossible.


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