Subject: [cicm] CICM Scope

From: "Novikov, Lev" <[email-masked]>
Date: Mon, 15 Aug 2011 17:19:56 -0400

(Cross-posted on the Cryptography mailing list at randombit.net)

I've been doing a bit of reading based on the comments we've received.

The results of the BOF at IETF 81 suggested we should broaden our
scope and discuss the impact of the CICM Model, particularly Security
Domain Separation, on (2 or more) existing IETF protocols.

Here are the suggestions we've heard to-date (in no particular order):
  * IPsec (suggested by almost everyone)
  * TLS (via Paul Hoffman, David McGrew)
  * AEAD (in RFC 5116; via David McGrew)
  * VPN establishment crypto protocols (via Alfonso De Gregorio)
  * Domain Security Services (as in RFC 3183; via Alfonso De Gregorio)

** Alfonso:
  Can you elaborate on which protocols you had in mind regarding VPN?

It seems clear that, at the very least, we should look at IPsec.

Perhaps first, however, we should put together a crisper version of
draft-lanz-cicm-lm "CICM Logical Model" which we can then use as the
basis for analysis to address questions like: (via David McGrew)

  * What benefit does the CICM model provide in cases where there
    isn't a strict separation between security domains?

  * How can the CICM model operate if only one of the communicating
    parties uses the model?

  * What is the impact of having queues between plaintext and
    ciphertext on:
    - latency
    - jitter
    - retransmission timers
    - TCP startup time
    - bufferbloat

  * What is the impact of not providing return codes to a secure-side
    application sending a packet? What about "no route to host" and 
    MTUs?

  * Regarding applying the CICM model to IPsec:
    - How would it map onto the IPsec Security Association Database?
    - Where do the different parts of the IPsec architecture reside?
    - How is information that needs to cross domains (e.g., TOS byte)
      handled?
    - How is ICMP handled?

At a higher level, we could also address questions such as:

  * How can we further push responsibility for performing cryptography
    correctly into the crypto (e.g., being responsible for
    initialization vectors)? (via David McGrew)

  * How can we improve integrity guarantees between security domains
    or among system-level components? (via Alfonso De Gregorio)

  * How can we improve the practice of transmitting and storing data 
    at mixed levels of sensitivity? (via Joe Mitola)

Other ideas / questions?

Are there other people / WGs we should get involved?

Lev

---

From: Alfonso De Gregorio <[email-masked]>
Date: Tue, 16 Aug 2011 04:41:49 +0200

Lev,

> It seems clear that, at the very least, we should look at IPsec.

Absolutely. Thanks for asking.

IPsec is the most natural protocol we should look at, indeed.

In my opinion, the Secure Shell Connection Protocol (RFC 4254) is also
to be consider among the (de-facto) VPN establishment crypto
protocols, if we consider its most popular implementation. Let me
elaborate why this is the case.

As we know, the SSH protocol doesn't provide a VPN establishment
mechanism built-in. However, at the connection layer the IETF standard
defines the channel mechanism and specify the first four basic channel
types. Real world implementations have the possibility to build upon
this mechanism extending the protocol to accommodate new use cases.

This is what OpenSSH did with the tunnel forward extension. As of
version 4.3, OpenSSH supports layer 2 and layer 3 tunnelling via the
"[email-masked]" channel type. On network endpoints equipped with
pseudo-device interface like the BSD tun(4), this extended channel
type allows to forward layer 2 frames and layer 3 packets back and
forth, and hence to establish an encrypted VPN connections.

Building on the above, there is yet another IETF protocol that we
might want to consider in order to discuss the impact of CICM Model
and it is iSCSI (RFC 3720).

If we try to frame a CICM-enabled-iSCSI endpoint in the use cases
detailed in draft-lanz-cicm-lm, we would find it related to both the
HAIPE and the data-at-rest cases.

iSCSI uses the IPsec mechanism for providing integrity, authentication
and confidentiality at the IP level between the initiator and the
target (RFC 3723). Here, considerations originating from to the
presence of queues (e.g., latency) may be especially relevant.

At the same time, the data-at-rest use case is also relevant, when we
relax the architectural constraints, moving the cryptographic-module
interface to the storage from a local bus to the network.

Cheers,

-- alfonso     blogs at http://Plaintext.crypto.lo.gy   tweets @secYOUre