Re: [cicm] CICM Scope
Alfonso De Gregorio <adg@crypto.lo.gy> Tue, 16 August 2011 02:41 UTC
Return-Path: <adg@crypto.lo.gy>
X-Original-To: cicm@ietfa.amsl.com
Delivered-To: cicm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1789A21F8CEF for <cicm@ietfa.amsl.com>; Mon, 15 Aug 2011 19:41:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjL6q1iqLHvI for <cicm@ietfa.amsl.com>; Mon, 15 Aug 2011 19:41:03 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6E35A21F8CED for <cicm@ietf.org>; Mon, 15 Aug 2011 19:41:03 -0700 (PDT)
Received: by pzk33 with SMTP id 33so6387753pzk.18 for <cicm@ietf.org>; Mon, 15 Aug 2011 19:41:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.143.18.21 with SMTP id v21mr2147959wfi.109.1313462509484; Mon, 15 Aug 2011 19:41:49 -0700 (PDT)
Received: by 10.142.112.19 with HTTP; Mon, 15 Aug 2011 19:41:49 -0700 (PDT)
X-Originating-IP: [195.32.92.139]
In-Reply-To: <F9AB58FA72BAE7449E7723791F6993ED0630D5F197@IMCMBX3.MITRE.ORG>
References: <F9AB58FA72BAE7449E7723791F6993ED0630D5F197@IMCMBX3.MITRE.ORG>
Date: Tue, 16 Aug 2011 04:41:49 +0200
Message-ID: <CAEk7eQQojy9-bzD-Qa=UEXq_6NXak9FfTZ61BDvzgMGPxMC+_Q@mail.gmail.com>
From: Alfonso De Gregorio <adg@crypto.lo.gy>
To: CICM Discussion List <cicm@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "cryptography@randombit.net" <cryptography@randombit.net>
Subject: Re: [cicm] CICM Scope
X-BeenThere: cicm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: CICM Discussion List <cicm@ietf.org>
List-Id: CICM Discussion List <cicm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cicm>, <mailto:cicm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cicm>
List-Post: <mailto:cicm@ietf.org>
List-Help: <mailto:cicm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cicm>, <mailto:cicm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Aug 2011 02:41:04 -0000
Lev, On Mon, Aug 15, 2011 at 11:19 PM, Novikov, Lev <lnovikov@mitre.org> wrote: > (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. 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 "tun@openssh.com" 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
- [cicm] CICM Scope Novikov, Lev
- Re: [cicm] CICM Scope Alfonso De Gregorio