Nicolas Williams
2008-04-08 23:59:25 UTC
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 -----
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 -----