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

[Nico Williams <[e-mail]>]

On Tue, Jun 21, 2011 at 2:19 PM, Novikov, Lev <[e-mail]> wrote:
> Cross-posted on <[e-mail]>.
> This is a discussion that started on the Cryptography mailing list:
> http://lists.randombit.net/pipermail/cryptography/2011-June/000940.html
>
> NOTE: You need to be a member to post on either list.
>  RandomBit: http://lists.randombit.net/mailman/listinfo/cryptography
>  IETF: https://www.ietf.org/mailman/listinfo/cicm

I suggest that you allow posts by non-subscribers who are subscribers
of any IETF lists -- I cannot subscribe to every IETF list.

> On 2011-06-21 14:25, Nico Williams wrote:
>> Even so, what value does this add over, any of the APIs and frameworks
>> we already have?
>>
>> If the issue is ensuring that you are able to login to tokens, why not
>> add suitable extensions to the GSS-API (basically a single function)?
>
> The issue is much broader.
>
> For example, here's a quote from RFC 2743 (GSS-API v2.1):
>> The client generates a data message and passes it to GSS_Wrap().
>> GSS_Wrap() performs data origin authentication, data integrity, and
>> (optionally) confidentiality processing on the message and
>> encapsulates the result into output_message, indicating
>> GSS_S_COMPLETE status. The client sends the output_message to the
>> server.
>
> This makes sense for many devices and environments. However, high
> assurance environments are more varied. For example, you may have two
> processes that control (in a mutually exclusive manner) the channel
> creation and negotiation (a Controller in CICM-speak) and the data flow
> on the channel (Stream).

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.

> Another example:
> In existing APIs, you can perform two operations by applying each
> operation in sequence on the plaintext (e.g., encrypt and sign).

Not in the GSS-API.  GSS wrap tokens cover both, confidentiality
(optional) and integrity protection automatically for you; no need to
think about how to do authenticated encryption.

> However, high assurance module often support atomic "hybrid" operations
> which cannot be accomplished with existing APIs when the data that is
> provided to the module does not return back to the calling program.

Do you mean AE and/or AEAD cipher modes?  The GSS-API most certainly
precludes neither (see above).

> I understand the desire to avoid creating new APIs when there are so
> many existing ones (surely one of them should do the trick!?). However,
> the feedback from users and vendors is that the underlying logical
> models of their devices is sufficiently different (and varied) from what
> existing APIs assume that it is difficult to retrofit their concepts and

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?

> requirements into those APIs. Among other reasons, this is why there is
> such a proliferation of proprietary APIs in these environments (which CICM
> is trying to unify, abstract, and standardize).

Whereas I suspect that proprietary APIs proliferate due to either a) a
vendor's desire to keep their APIs proprietary, b) accidental
ignorance of existing alternatives.  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.

[0] http://tools.ietf.org/html/draft-ietf-nfsv4-rpcsec-gssv3-00

Nico
--