[anonsec] [FWD: tsv-dir review of draft-ietf-btns-connection-latching-06]

Nicolas Williams <Nicolas.Williams@sun.com> Wed, 09 April 2008 00:07 UTC

Return-Path: <anonsec-bounces@postel.org>
X-Original-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com
Delivered-To: ietfarch-btns-archive-waDah9Oh@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A38A83A6A69 for <ietfarch-btns-archive-waDah9Oh@core3.amsl.com>; Tue, 8 Apr 2008 17:07:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.548
X-Spam-Level:
X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YewBGAbKbNCR for <ietfarch-btns-archive-waDah9Oh@core3.amsl.com>; Tue, 8 Apr 2008 17:07:40 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 221633A69D5 for <btns-archive-waDah9Oh@lists.ietf.org>; Tue, 8 Apr 2008 17:07:40 -0700 (PDT)
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m39007LN026563; Tue, 8 Apr 2008 17:00:07 -0700 (PDT)
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m38NxVv0026479 for <anonsec@postel.org>; Tue, 8 Apr 2008 16:59:32 -0700 (PDT)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m38NxUTV016396 for <anonsec@postel.org>; Tue, 8 Apr 2008 23:59:31 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m38NxUIW035593 for <anonsec@postel.org>; Tue, 8 Apr 2008 17:59:30 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m38NxQF4006363; Tue, 8 Apr 2008 18:59:26 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m38NxPGf006362; Tue, 8 Apr 2008 18:59:25 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Tue, 8 Apr 2008 18:59:25 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: anonsec@postel.org
Message-ID: <20080408235925.GW16998@Sun.COM>
Mail-Followup-To: anonsec@postel.org, julien.ietf@laposte.net, lha@stacken.kth.se, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.7i
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: nicolas.williams@sun.com
Cc: lha@stacken.kth.se, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, julien.ietf@laposte.net
Subject: [anonsec] [FWD: tsv-dir review of draft-ietf-btns-connection-latching-06]
X-BeenThere: anonsec@postel.org
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Discussions of anonymous Internet security." <anonsec.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/anonsec>, <mailto:anonsec-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/anonsec>
List-Post: <mailto:anonsec@postel.org>
List-Help: <mailto:anonsec-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/anonsec>, <mailto:anonsec-request@postel.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: anonsec-bounces@postel.org
Errors-To: anonsec-bounces@postel.org

Hannes sent this review and graciously allowed me to post it to the
list.

My responses will follow.

Nico


----- Forwarded message from Hannes Tschofenig <Hannes.Tschofenig@gmx.net> -----

Date: Tue, 08 Apr 2008 14:18:33 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Subject: tsv-dir review of draft-ietf-btns-connection-latching-06
To: tsv-dir@ietf.org
Cc: Nicolas.Williams@Sun.COM, julien.ietf@laposte.net, lha@stacken.kth.se

I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to
allow them to address any issues raised. The authors should consider
this review together with any other last-call comments they
receive. Please always CC tsv-dir@ietf.org if you reply to or forward
this review.


I had to review draft-ietf-btns-connection-latching-06 and I have to admit that I did not follow the work in the BTNS group. 
Hence, I had to read through all the drafts to understand what you are doing. In some sense I am thankful to Magnus that he assigned me this task since I would not have looked at this work otherwise. Sorry that my review arrives so late. 

I couldn't see specific issues from a transport area directorate point of view related to this document. With this respect the document is essentially fine. 
Many aspects in the draft would, however, best be verified by an implementation. I hope that someone has done that. Is there code available? 

Still, I would like to share some my thoughts with you when I read through your specs. 

Initially, I thought I knew what I could expect under the title of "Better-Than-Nothing security". I was looking for a "leap of faith" type of solution. As it turns out that this is only one aspect (and probably the least important one) and the overall security at the end (with the application layer authentication and channel bindings) in some other deployment modes provides good and deployable security. 

The next trap was obviously the term "channel binding" since I knew it from EAP already and it may have a different meaning, at least RFC 5056 "On the Use of Channel Bindings to Secure Channels" claims that it is different even though I did not really understood the argument. There are some assumptions these channel bindings in this work are somewhat difficult to understand, at least for me. For example, here is the definition from RFC 5056: 

"
 o  Channel binding: the process of establishing that no man-in-the-
      middle exists between two end-points that have been authenticated
      at one network layer but are using a secure channel at a lower
      network layer.  This term is used as a noun.
"

In some other places I got the impression that the authentication may happen at the application layer. I was wondering whether the ISO-OSI layer model is the important part of the story in order to capture the assumptions and applicability well (when the mechanism claims to be generic). 

The benefit of the work is also difficult to capture:

  * RFC 5056 indicates the benefit of the approach mainly related to performance. Example:
"
   The main goal of channel binding is to be able to delegate
   cryptographic session protection to network layers below the
   application in hopes of being able to better leverage hardware
   implementations of cryptographic protocols. 
"

  * There is also the security aspect of providing security protection at the lower layer while authentication happens at the higher layers, such as transport protection from packet spoofing. This is described in draft-ietf-btns-prob-and-applic-06.txt (by potentially anticipating solutions in the BGP space).

  * draft-ietf-btns-prob-and-applic-06.txt points generally to benefits for different applications, such as the transport of voice-over-IP (VoIP), IMAP server communication, protecting transport connections for commercial web servers, transport for streaming media, file system protocols (such as iSCSI and NFS). 

  * Finally, there are general discussions on the advantages providing security at lower layers and to avoid multiple authentication steps at different layers (see for example Section 2.2.3 of draft-ietf-btns-prob-and-applic-06.txt). 

   The statements in Section 2.1.2 of draft-ietf-btns-prob-and-applic-06.txt ("Authentication Methods") appear wrong to me when considering EAP usage in IKEv2. The text says:

"CA-signed certificates and pre-shared secrets 
   are the only methods of authentications accepted by current IPsec and 
   IKE specifications.
"

Reading through the documents I could imagine that some folks, who are supposed to be using some of these concepts, could get confused. Consider that you are also targeting application layer guys. They might not even come up with the idea to use IPsec and the documents have a heavy IPsec/IKE touch even though the concepts are more generally applicable (I believe). For example, when I look at http://tools.ietf.org/id/draft-johansson-http-tls-cb-02.txt that seems to fit into the entire stream of work. Maybe you went a bit too far with the abstraction and hence your work is not so easy to understand anymore. For example, the channel binding definition from RFC 5056 shown above does not fit nicely to something described in draft-johansson-http-tls-cb-02.txt; it more naturally fits into IPsec. 

I mentioned some of the benefits you see for your work. I would like to focus on one aspect only, namely VoIP security, since I worked in this space for a while now. As part of that work I never came across BTNS. On the other hand, nobody from the BTNS working group approached us either, particularly since you seem to assume that "we" are potential customers of your technology. I provide you a bit more details about what we do and maybe the stuff just sounds like "channel bindings" but in fact isn't. I don't know. In any case, it might show you that 
* you have not done a lot of marketing for your work (I hope you do not believe that everyone follows everything else going on in the IETF anyway and your work ends with writing a draft.) 
* every application case may be a bit different and there may not be so many usages for your stuff as you might think. 
For example, security vulnerabilities with TCP might not be a convincing argument for many people in the application area. They often have more severe attacks to worry about. 

In SIP we are working on a VoIP media security solution and after a long time we decided to go for DTLS-SRTP. The details don't matter but consider the following high-level framework http://www.ietf.org/internet-drafts/draft-ietf-sip-dtls-srtp-framework-01.txt:

                 +-----------+            +-----------+
                 |SIP        |   SIP/SDP  |SIP        |
         +------>|Proxy      |----------->|Proxy      |-------+
         |       |Server X   | (+finger-  |Server Y   |       |
         |       +-----------+   print,   +-----------+       |
         |                      +auth.id.)                    |
         | SIP/SDP                              SIP/SDP       |
         | (+fingerprint)                       (+fingerprint,|
         |                                       +auth.id.)   |
         |                                                    |
         |                                                    v
     +-----------+          Datagram TLS               +-----------+
     |SIP        | <-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-> |SIP        |
     |User Agent |               Media                 |User Agent |
     |Alice@X    | <=================================> |Bob@Y      |
     +-----------+                                     +-----------+

     Legend:
     ------>: Signaling Traffic
     <-+-+->: Key Management Traffic
     <=====>: Data Traffic

   Figure 1: DTLS Usage in the SIP Trapezoid


The entire exchange starts with a SIP traveling along the SIP proxy and carrying a fingerprint that identifies the certificate). The fingerprint story is essentially taken from http://www.ietf.org/rfc/rfc4572.txt. There are several ways one can do the authentication at the SIP layer; a more complicated story. 

Hence, just assume that Alice would be authenticated to Bob at the application layer (here SIP). The DTLS exchange between the end points is essentially not authenticated in many cases. To create a relationship between the SIP signaling session and the DTLS exchange (and the subsequent media) the fingerprint conveyed in the SIP exchange would refer to the certificate that will be presented for the TLS session. 

This might similar to your channel bindings idea even though we don't say anything about channel binding here at all (and I wouldn't even know why we should). We wouldn't make use of anything from draft-ietf-btns-connection-latching-06.txt or draft-ietf-btns-core-06.txt since we don't use IPsec. There are good reasons for not using IPsec in this space: SRTP is specifically designed for voice with a low overhead and the industry had already bought into it. The stuff is available in the respective devices in hardware. When we initially proposed RTP over DTLS (see http://tools.ietf.org/html/draft-tschofenig-avt-rtp-dtls-00) and we got beaten up for using the TLS record layer instead of SRTP. Consequence: We quickly changed to http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp-00).

There is, however, another document that could make use of some of your stuff, namely http://www.ietf.org/internet-drafts/draft-tschofenig-hiprg-host-identities-06.txt. It uses IPsec (as HIP currently uses IPsec) but I have to admit that it belongs more to the academic track rather than something that is pending deployment.

Also related to to this work there is an old 3GPP specification that uses IPsec between the SIP User Agent and it's outbound SIP proxy. It does not use IKE but uses the authentication and key exchange defined in SIP (digest authentication) and SIP security agreement to essentially accomplish the same functionality as IKE. There, I believe, your IPsec API concept could have been useful. Unfortunately, that was many years before you did your work and hence they already did their own stuff. I am also not sure about the widespread deployment. 


Ciao
Hannes

PS: A minor comment regarding the following statement: 

"
   o  Implementations that provide such programming interfaces SHOULD
      make available to applications any available NAT-related
      information about the peer: whether it is behind a NAT and, if it
      is, the inner and outer tunnel addresses of the peer.
"

I don't see how IKE would be able to obtain this information in a reliable fashion. I suggest to delete this paragraph. 
If you want to learn more about the complexity of NAT traversal I suggest to read through STUN, TURN, ICE and other BEHAVE documents. 

----- End forwarded message -----
_______________________________________________