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

[Nicolas Williams <[e-mail]>]

On Tue, Apr 08, 2008 at 14:18:33 +0200, Hannes Tschofenig wrote:
> 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 [e-mail] if you reply to or forward
> this review.

Thank you!

> 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. 

Thank you, that is a lot of reading.

> 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.

Thanks.  I'm in the process of preparing -07, which will have some new
material relevant to a tsv-dir review, namely listing the events for
TCP, UDP and SCTP that cause creation/release of connection latches.
These details are entirely obvious from -06, but I thought calling them
out specifically would be useful, particularly for SCTP, whose
multi-homing features might otherwise seem at odds with connection
latching (it isn't).

>                    Many aspects in the draft would, however, best be
> verified by an implementation. I hope that someone has done that. Is
> there code available? 

There exist two implementations, one in OpenSolaris and the other, IIRC,
in OpenSwan.

The OpenSolaris implementation is based on the informative model of
connection latching in section 2.3 of -06, and it's not entirely
complete, but it has been such as it is for years (since Solaris 9 was
released).  The source code is available at opensolaris.org and you can
search it for ipsec_latch_t to get started.

> 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). 

Authentication, indeed, is intended to happen at the application layer,
but to keep things generic I opted to write of "network layers" (after
all, the application layer is layer 7 in the OSI model, but
authentication might happen at the presentation layer, as in RPCSEC_GSS,
for example).

> 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).

That's one of several security benefits of channel binding.

>   * 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). 

Indeed.  I've not done any work towards applying BTNS, connection
latching or channel binding to any of those areas.  Except recently I've
begun collaborating with others on channel binding to TLS for
applications such as IMAP -- but that will not be using any BTNS WG
technologies.

>   * 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.
> "

I think in the end-to-end IPsec case this is generally true, and in the
SG use cases of IPsec it's generally false.  The text could perhaps use
some clarification on this point.

> 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 think you must be referring to the trusted proxy termination of
channels in draft-johansson-http-tls-cb-02.  Although this notion is not
described in RFC5056, it is a straightforward extension of the channel
binding concept described in RFC5056.  Leif, myself and others did
consider whether to include that extension in RFC5056, but for want of
finishing RFC5056 sooner, rather than later, we did not.

> 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.) 

Channel binding in general is, in fact gaining traction, and I think
we'll soon see specifications for specific app protocols progressed and
implementations deployed.

> * every application case may be a bit different and there may not be
> so many usages for your stuff as you might think. 

I agree.  Channel binding has to be fit separately into each application
that could benefit from it; it's not simply a matter of using existing
channel binding "slots" in existing APIs -- even where they exist, as in
the case of the GSS-API, there may be application-specific
considerations that have to be taken into account.

> 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. 

I agree!

> 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).

This is, in fact, channel binding, in the RFC5056 sense.

You don't have to state it for it to be so.

>                      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.

Indeed, you wouldn't.

The BTNS problem and applicability statement does claim that BTNS and
connection latching and channel binding would be useful for such
applications, and, indeed, use BTNS WG technology for SIP.  BUT, DTLS
was there, and it was available sooner than these other things (which,
in fact, aren't yet available).

So, yes, you wouldn't use IPsec for SIP.

In my opinion this is a failing of IPsec: you can't even conceive of
using IPsec for an application like SIP with Internet-scale deployment
without first adding connection latching and IPsec APIs.

>                                                       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).

I was aware of this, and I agree.

> 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.

HIP effectively uses channel binding.

> 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. 

IKEv2 has a NAT traversal feature.  I use it all the time.  It works.

Nico
-- 
_______________________________________________