Discussion:
[anonsec] [FWD: tsv-dir review of draft-ietf-btns-connection-latching-06]
Nicolas Williams
2008-04-08 23:59:25 UTC
Permalink
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 at gmx.net> -----

Date: Tue, 08 Apr 2008 14:18:33 +0200
From: Hannes Tschofenig <Hannes.Tschofenig at gmx.net>
Subject: tsv-dir review of draft-ietf-btns-connection-latching-06
To: tsv-dir at ietf.org
Cc: Nicolas.Williams at Sun.COM, julien.ietf at laposte.net, lha at 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 at 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 at X | <=================================> |Bob at 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 -----
Nicolas Williams
2008-04-09 01:05:54 UTC
Permalink
Post by Nicolas Williams
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 at ietf.org if you reply to or forward
this review.
Thank you!
Post by Nicolas Williams
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.
Post by Nicolas Williams
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).
Post by Nicolas Williams
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.
Post by Nicolas Williams
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
"
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).
Post by Nicolas Williams
"
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.
Post by Nicolas Williams
* 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.
Post by Nicolas Williams
* 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
"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.
Post by Nicolas Williams
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.
Post by Nicolas Williams
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.
Post by Nicolas Williams
* 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.
Post by Nicolas Williams
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!
Post by Nicolas Williams
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
+-----------+ +-----------+
|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 at X | <=================================> |Bob at Y |
+-----------+ +-----------+
------>: 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.
Post by Nicolas Williams
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.
Post by Nicolas Williams
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.
Post by Nicolas Williams
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.
Post by Nicolas Williams
"
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
--

Loading...