Re: KITTEN: IETF 75 - 76

[Nicolas Williams <[e-mail]>]

On Tue, Aug 18, 2009 at 11:05:03AM -0700, Love Hörnquist Åstrand wrote:
> I find PGSSAPI very distasteful.

If we could go back in time and make that first argument to all GSS
functions be an opaque pointer, a handle to an abstract app/lib context,
that'd be OK, yes?

I'm proposing that we do just that, only without the time travel part,
and with just a bit of backwards compatibility in the mechglue to detect
old apps / old mechs that expect that argument to be a OM_uint32 *.

That bit of backwards compatibility would be quite isolated, and it'd be
very similar to existing code in MIT krb5 to intern handles (in order to
distinguish between old apps and new ones, properly obtained handles
would have to be interned).

> >Also, I don't agree that there's no way to add new token types, if
> >that's what you meant.  You could add support for new tokens (e.g.,
> >re-key tokens, default QoP cipher change, ...) as follows:
> 
> There is no way to add more input variables to ISC.

Indeed.

> ISC have been extended to day, for example for NFS. you have to  
> acquire a special NFS credentials, modify the credential to select  
> what enctypes the kernel supports, and then call ISC. This doesn't  
> work for credential when you talk to different servers that have  
> diffrent properties, like TLS channel bindings.

Yes.

> I'm not worried about rekeying, if you want to tackle that we are  
> redoing the whole gss-api model.

Not really.  The SSPI does it, and the SSPI is very similar to the
GSS-API.  Re-keying would be an incremental change, not a fundamental
one (but it would require updates to app protocols in order for them to
be able to use it).  For SASL re-keying would be much more intrusive .
No, I don't care about re-keying.