Re: [cicm] CICM Channels and GSS (was Re: IETF Working Group Charter on Common Interface to Cryptographic Modules (CICM))

["Novikov, Lev" <[e-mail]>]

Nico,

On 2011-06-23 20:08, Nico Williams wrote:
> Nothing stops you from building an application that has several
> sub-channels built on existing technologies.
> 
> I'd be happy with you specifying such a protocol as long as it is on
> top of existing secure channel technology, or, as long as you show why
> that just won't do (I'm open to that possibility).  (I could also end
> up on the rough side of consensus, but I'd rather make CICM palatable
> to a larger audience.)
> 
> Also, you can structure privilege separation with only one channel.
> And you can bind multiple authentications into one channel (for an
> example of this see RPCSEC_GSSv3[0]).  You'll want to make sure that
> you cover why such alternatives are not appropriate.
> [...]
> GSS wrap tokens cover both, confidentiality (optional) and integrity 
> protection automatically for you; no need to think about how to do 
> authenticated encryption.
> [...]
> Some of the experts you need are in the KITTEN WG.  I'm sure KITTEN WG
> participants will be happy to talk to you about these issues, or to
> put you in contact with other KITTEN WG participants.  We have been
> *adding* to the GSS-API to make it meet our needs.  Surely you might
> consider the same approach?
> [...]
> In this case it seems I have to educate myself as to your needs,
> but I'm not sure that you and/or other CICM proponents are really up 
> to date on the GSS-API.  I don't mean that you should be an expert in 
> the GSS-API before setting out to build something like CICM, but it 
> would be good to make sure that CICM, or parts of it, are not 
> predicated on misconceptions about existing APIs.

Clearly, I need to make a better effort at being educated about GSS-API.
I'll be in touch with the KITTEN folks, per your suggestion.

In brief, you'd like to know CICM can't use GSS-API and:
  * use existing secure channel technologies,
  * enforce privilege separation in a single channel,
  * bind multiple authentications into a single channel,
  * or extend GSS-API to meet (other) high assurance needs?

Am I missing anything?

Thanks,
Lev