Re: KITTEN: IETF 75 - 76

[Nicolas Williams <[e-mail]>]

On Mon, Aug 17, 2009 at 06:49:37PM +0200, Love Hörnquist Åstrand wrote:
> 17 aug 2009 kl. 01:51 skrev Nicolas Williams:
> >(2) is really listing of principal names for which the caller has
> >credentials (we can already list mechanisms for which the caller has
> >credentials).  This is likely a difficult thing to design since we
> >will want to be able to control what principals
> >GSS_Accept_sec_context()  can accept sec contexts for, and that means
> >a significant revamp of the semantics of CREDENTIAL HANDLEs _or_ a
> >replacement for GSS_Accept_sec_context().
> 
> accept sec context is not really intresting since it doesn't make  
> thinks not work. init sec context however it mostly useless since the  
> consumers don't know about what credentials they have.

Acceptors with creds for multiple principals have little choice but to
use GSS_C_NO_CREDENTIAL and check the resulting security context to see
if the acceptor principal (and mech, and, if we ever add it, QoP policy)
is acceptable to the app.  That's lame.  I'd rather be able to acquire a
CREDENTIAL HANDLE for all the principals I'm willing to accept sec
contexts for and then use that.

The GSS-API concept of CREDENTIAL HANDLEs is a set of credentials for
the same principal, but different mechanisms.  Changing this to allow it
to be a set of credentials for any {mechanism, principal} seems...
difficult, but perhaps fun anyways.

> have a list of mechs there is credentials for is also mostly useless,
> i have [e-mail] (Kerberos), SU.SE\lha (NTLM), KTH.SE (Kerberos)
> E.KTH.SE (sasl-digest-md5),
> [e-mail]1:EA35DAB08BD8EC833C160FAFCDF03E4B13F72D6B (Kerberos) any
> many other, knowing that I have some Kerberos credentals is mostly
> useless.

Yes, this problem affects initiators too.  If you want to solve the
Identity Selection problem _above_ the GSS-API (and I agree that the
solutions do belong outside the GSS-API), then you need to solve the
CREDENTIAL HANDLE issue first.

[For the benefit of lurkers: in practice though you always have a
"default" principal, and you have to be able to choose a principal to
use in any given context.  The Identity Selection problem is not as easy
to solve as simply letting CREDENTIAL HANDLEs be sets of creds for any
{mech, princ}, but that is a very helpful first step.]

> >>  4. error message reporting
> >
> >Yes.  (I still believe in the "PGSSAPI" idea where, in the C bindings,
> >we change the semantics and type of the minor_status argument,  
> >though in
> >a binary backwards compatible way.  I can expand if desired.)
> 
> Lets redo the api, ISC is broken as it since there is no way to add  
> new tokens.

ISC?

I don't want to re-design the API from scratch if we can avoid it.
Moreover, all of the enhancements we're discussing are incremental,
_except_ for this one and the multi-princ credentials one; this one fits
right in as proposed above, and we can solve the multi-princ credentials
problem incrementally too.  If we had more problems to fix that are not
incremental then I'd agree on a whole re-design.

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:

a) provide a way to indicate that the app supports the new thing (this
   could be a credential handle property, but it could also be done
   using the PGSSAPI proposal);
b) provide new functions to output the new token types;
c) provide new major status codes (for existing per-msg token generating
   functions) indicating that the caller must first engage in some other
   type of token exchange (e.g., re-key);
d) provide new major status codes (for existing per-msg token consuming
   functions) indicating that an input token is of the wrong type (so
   the caller may then call the correct function with it).

(a) and (b) are the bare minimum that must be done, but you need (c) if
you want async re-keys (i.e., if you want the mech to decide when a
re-key is needed).  (d) is not strictly needed: app protocols have to be
revised anyways to use new token types, so we can expect apps to
identify token types.

> >>  5. asynchronous calls
> >
> >Developers can use threads to work around the lack of these, so it  
> >seems
> >to me that these should be a lower priority.
> 
> I disagree, threads consume lots of resources that and are very  
> complicated to use.

I agree that async versions are desirable.  I believe the other items on
Shawn's list are more important though, that's all.

> >>...along with Alexey's recent request for policy/encryption strength.
> >
> >Yes.  This should be, IMO, a high priority.
> 
> And not over engineered. Let's solve the SASL problem and nothing more.

I agree.  I want nothing to do with, for example, a language for
expressing cryptographic quality of protection policies.  I want only a
way to obtain non-hard-coded, context-specific policies.  The key is
context-specific (because the Kerberos mech can use any enctype in a
context-specific way -- you can't tell which it is just from the mech's
OID, unlike SCRAM).  (A context-specific SSF number is acceptable to
me as a way to support SASL.)

Nico
--