On Tue, Jun 21, 2011 at 2:19 PM, Novikov, Lev <[email protected]> wrote: > Cross-posted on <[email protected]>. > 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 -- _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
