[prev in list] [next in list] [prev in thread] [next in thread]
List: ipsec
Subject: Re: [IPsec] draft-ietf-ippm-ipsec-01 review
From: "Zhanglijia (A)" <emma.zhanglijia () huawei ! com>
Date: 2013-11-01 7:29:09
Message-ID: CE92CE3FCF47934CBAE2CCECE119606C6338C6B6 () nkgeml507-mbs ! china ! huawei ! com
[Download RAW message or body]
[Attachment #2 (text/plain)]
Hi John, all
Many thanks for the review! Please see the reply as bellow.
Best Regards
Emma
-----邮件原件-----
发件人: ippm-bounces@ietf.org<mailto:ippm-bounces@ietf.org> \
[mailto:ippm-bounces@ietf.org] 代表 John Mattsson 发送时间: 2013年10月23日 \
5:37 收件人: ippm@ietf.org<mailto:ippm@ietf.org>
主题: [ippm] draft-ietf-ippm-ipsec-01 review
Hi,
I reviewed draft-ietf-ippm-ipsec-01, I think the issue is important, and I think the \
document is a good start. I do however have some the doubts regarding the suggested \
solution to extract keying material from IPsec.
Here are my comments and suggestions.
Best Regards
John
Comments on draft-ietf-ippm-ipsec-01
---------------------------------------------
In general I think the abstract and Introduction could be clearer in what the \
problems and use cases are and what the document tries to achieve. E.g. do the \
document want to measure the performance of IPsec or use IPsec for protection, or \
both. What are the problems, if any, of just sending O/TWAMP over the existing IPsec \
tunnel?
Emma: The draft currently aims to capitalize on IPsec for deriving keys for O/TWAMP. \
We will further edit the introductory text to address this point.
- [Abstract]
"it extends the applicability of O/TWAMP to networks that have already deployed \
IPsec"
"Unfortunately, however, standard IP performance measurement security mechanisms \
cannot be readily used with IPsec."
This gives the idea that you cannot use O/TWAMP with IPsec, but this is of course not \
true. You can e.g. send O/TWAMP over IPsec, and depending on the IPsec security \
policy database (SPD) you can send O/TWAMP outside of the IPsec tunnel.
Emma: Thanks for the comment. This was not our intention. Indeed O/TWAMP security and \
IPsec can be deployed and run separately. But given that the currently standardized \
O/TWAMP security mechanisms only support pre-shared key mode, large scale deployment \
and use is hindered significantly as mentioned in the draft. Deployment of "shared \
secrets" for massive equipment installation is not the best idea after all, I hope \
you agree with that. We will edit the text to address this.
- [Section 1]
"In particular, we note that it is not necessary to use distinct keys in \
OWAMP-Control and OWAMP-Test layers. One key for encryption and another for \
authentication is sufficient for both Control and Test layers. This obviates the \
need to generate two keys for each layer and reduces the complexity of O/TWAMP \
protocols in an IPsec environment. This observation comes from the fact that \
separate session keys in the OWAMP-Control and OWAMP-Test layers were designed for \
preventing reflection attacks when employing the current mechanism."
I assume O/TWAMP uses different keys as is it bad security design to use the same key \
for two different purposes. Using the same key twice may leads a number of security \
problems
- It easily causes so called "two-time pads" were the confidentiality is totally \
compromised.
- For some algorithms the integrity may be compromised.
- If one use of the keys has a cryptographic weakness so than an attacker can recover \
the key, the attacker has the use that key to attack both uses of the key.
- It gives an attacker twice as much material (protected traffic) to work with.
I therefore strongly recommends against using the same key twice unless you must, and \
in this case we do not.
Emma: Well, the draft does not exclude the use of distinct keys. Actually there are \
three options (basic + 2 alternatives) in the draft and we have already called for \
active discussion in the WG on which one is better, and we appreciate opening the \
technical discussion on this matter. The threats above can be considered when \
determining which option should be standardized.
- [Section 3.1]
The Server-Start message with Server-IV is missing from the text.
Suggestion:
"In the authenticated and encrypted modes, all further communication is encrypted \
using the AES Session-key and authenticated with the HMAC Session-key. After \
receiving Set-Up-Response the server responds with a Server-Start message containing \
Server-IV. The client encrypts everything it transmits through the just-established \
O/TWAMP-Control connection using stream encryption with Client-IV as the IV."
Emma: OK with this suggestion.
- [Section 4]
I think "IPsec SA" is old terminology for IKE(v1), all occurrences should be changed \
to "Child SA".
Emma: OK with this suggestion.
- [Section 4]
"Therefore, even if the peers choose to opt for the unauthenticated mode, IPsec \
integrity protection is extended to O/TWAMP.
I think the document would be improved by discussing this and other options:
O/TWAMP unauthenticated over existing Child SA with integrity.
O/TWAMP unauthenticated over existing Child SA with encryption.
O/TWAMP unauthenticated over existing Child SA with encryption and integrity.
O/TWAMP unauthenticated over new Child SA with encryption and or integrity.
in a separate section before the section on extracting keying material. It may very \
well be the case that O/TWAMP unauthenticated over the existing Child SA fulfills the \
user's security requirements.
Emma: The options listed above existed. But in this case, O/TWAMP layer should obtain \
the information about IPsec layer first (e.g. Child SA with integrity and/or \
encryption). The interaction between O/TWAMP layer and IPsec layer will increase.
- [Section 3.4]
"If the AH protocol is used, IP packets are transmitted in plaintext. The \
authentication part covers the entire packet. So all test information, such as UDP \
port number, and the test results will be visible to any attacker, which can \
intercept these test packets, and introduce errors or forge packets that may be \
injected during the transmission. In order to avoid this attack, the receiver must \
validate the integrity of these packets with the negotiated secret key."
As the packeges are authenticated an attacker cannot forge or inject errors. And as \
the packages are not encrypted, reading the information cannot be considered an \
attack.
I suggest deleting " to any attacker, which can intercept these test packets, and \
introduce errors or forge packets that may be injected during the transmission. In \
order to avoid this attack, the receiver must validate the integrity of these packets \
with the negotiated secret key.
Emma: OK with this suggestion.
- [Section 3.4, Section 4]
"If ESP is used, IP packets are encrypted"
"When using ESP, all IP packets are encrypted"
This is not true as ESP can be used with only integrity protection (NULL cipher). In \
fact, I think this is far more common than using AH. Instead of start talking about \
AH, I think the draft could list the three different ESP options (integrity and/or \
encryption) and then have a note stating that for AH have similar properties as ESP \
with NULL cipher.
Emma: OK with this suggestion.
- [Section 4]
From a security perspective it would be very bad to allow extraction of SKEYSEED or \
KEYMAT. They could be used to passively eavesdrop on the IPsec traffic or to \
alter/inject messages. Even if we trust the O/TWAMP application to not be malicious, \
use of the same key in another application may cause security problems such as \
two-time pad, which completely compromises the confidentiality.
A secure solution would be that the IPsec API returns a key that is derived from some \
of IPsec keying material. E.g. a new "KEYMAT" derived using some new random material \
instead of (Ni,Nr), e.g.:
Shared secret = prf+( SK_d, SID )
Or a key derived from KEYMAT:
Shared secret = PRF( KEYMAT, SID )
I strongly suggest removing the options that exposes the IPsec keying material, only \
keeping secure options, and adding text describing that it is the IPsec \
implementation that performs the key derivations.
Emma: We agree that from a security pov deriving shared key at IPsec is a better \
choice. We can consider that in next version.
- [Section 4]
While extracting keying material from IPsec would be nice, to my knowledge there is \
no standardized (or de facto standard) API to extract SKEYSEED, SK_d, KEYMAT or even \
SPI from an IPsec implementation. This was even one of the reasons IPsec was not \
chosen as the default security protocol for O/TWAMP. You could of course do it with a \
new proprietary implementation, but that kind of beats some of the purpose from the \
Abstract "gaining popularity in several deployment scenarios".
Work on an IPsec API started a couple a years ago \
http://tools.ietf.org/html/draft-ietf-btns-ipsec-apireq-00
but died, and even that work did prohibit extraction of keying material and \
discouraged the extraction of SPI as the SPI might change.
Has the API proposals been discussed in the ipsecme working group?
Emma: We received this comment at the last meeting (I think it was Yoav who commented \
on that). We believe that this is in fact implementation-dependent. For example, for \
those with existing IPsec and O/TWAMP implementations this should not be a blocking \
point. If there was a "standard" API, this protocol could benefit. But what we're \
interested primarily here is O/TWAMP deployment at large scale and for networks that \
have already deployed IPsec.
- [Section 4]
I think the approach in Section 4 with extracting keying material would only work \
with a proprietary IPsec implementation and modifications (adding new fields) to \
O/TWAMP.
Have approaches that do not require extracting keying information been considered?
Emma: I think we could discuss this in Vancouver. In the meantime, do you have text \
to suggest?
If the Child SA is encrypted, a simpler approach would be to transfer the O/TWAMP \
shared secret in a similar manner as the O/TWAMP session key, e.g. in the KeyID \
field. This would just require changes to the function in the O/TWAMP that receives \
the shared secret, and no modifications to IPsec.
At least if the Child SA is integrity protected, one approach would be to use \
Diffie-Hellman in O/TWAMP. This would still require new O/TWAMP fields but still be \
easier than the current suggestion as it does not require any changes to IPsec.
A problem is still the lack of API to find out whether encryption or integrity is in \
use.
Minor editorial comments on draft-ietf-ippm-ipsec-01
------------------------------------------------------------------
- [s3.1] "OWAMP-Control commands" -> "O/TWAMP-Control commands"
- [s4] "must be generated firstly" -> "must be generated first"
- [s4] "session ID is is the"
Emma: OK with these editorial comments.
------------------------------------------------------------------------------------
JOHN MATTSSON
MSc Engineering Physics, MSc Business Administration and Economics Senior Researcher, \
Security
Ericsson AB
Security Research
Färögatan 6
SE-164 80 Stockholm, Sweden
Phone +46 10 71 43 501
SMS/MMS +46 76 11 53 501
john.mattsson at ericsson.com
www.ericsson.com<http://www.ericsson.com>
_______________________________________________
ippm mailing list
ippm@ietf.org<mailto:ippm@ietf.org>
https://www.ietf.org/mailman/listinfo/ippm
[Attachment #3 (text/html)]
<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns="http://www.w3.org/TR/REC-html40"> <head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:宋体;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@宋体";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
text-align:justify;
text-justify:inter-ideograph;
font-size:10.5pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"纯文本 Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.5pt;
font-family:"Calibri","sans-serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"批注框文本 Char";
margin:0cm;
margin-bottom:.0001pt;
text-align:justify;
text-justify:inter-ideograph;
font-size:9.0pt;
font-family:"Calibri","sans-serif";}
span.Char
{mso-style-name:"纯文本 Char";
mso-style-priority:99;
mso-style-link:纯文本;
font-family:"Calibri","sans-serif";}
span.Char0
{mso-style-name:"批注框文本 Char";
mso-style-priority:99;
mso-style-link:批注框文本;
font-family:"Calibri","sans-serif";}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="ZH-CN" link="blue" vlink="purple" style="text-justify-trim:punctuation">
<div class="WordSection1">
<p class="MsoPlainText"><span lang="EN-US">Hi John, all<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">Many thanks for the review! Please see the \
reply as bellow. <o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">Best Regards<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">Emma<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US" \
style="color:#1F497D"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">-----</span><span style="font-family:宋体">邮件原件</span><span \
lang="EN-US">-----<br> </span><span style="font-family:宋体">发件人</span><span \
lang="EN-US">: <a href="mailto:ippm-bounces@ietf.org"> ippm-bounces@ietf.org</a> [<a \
href="mailto:ippm-bounces@ietf.org">mailto:ippm-bounces@ietf.org</a>] </span><span \
style="font-family:宋体">代表</span><span lang="EN-US"> John Mattsson<br> \
</span><span style="font-family:宋体">发送时间</span><span lang="EN-US">: \
2013</span><span style="font-family:宋体">年</span><span \
lang="EN-US">10</span><span style="font-family:宋体">月</span><span \
lang="EN-US">23</span><span style="font-family:宋体">日</span><span lang="EN-US"> \
5:37<br> </span><span style="font-family:宋体">收件人</span><span lang="EN-US">: \
<a href="mailto:ippm@ietf.org"> ippm@ietf.org</a><br>
</span><span style="font-family:宋体">主题</span><span lang="EN-US">: [ippm] \
draft-ietf-ippm-ipsec-01 review<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">Hi,<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">I reviewed draft-ietf-ippm-ipsec-01, I think the issue is important, and \
I think the document is a good start. I do however have some the doubts regarding the \
suggested solution to extract keying material from IPsec.<o:p></o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US">Here are my comments and \
suggestions.<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">Best Regards<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">John<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">Comments on draft-ietf-ippm-ipsec-01<o:p></o:p></span></p> <p \
class="MsoPlainText"><span \
lang="EN-US">---------------------------------------------<o:p></o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US">In general I think the abstract and \
Introduction could be clearer in what the problems and use cases are and what the \
document tries to achieve. E.g. do the document want to measure the performance of \
IPsec or use IPsec for protection, or both. What are the problems, if any, of just \
sending O/TWAMP over the existing IPsec tunnel? <o:p></o:p></span></p>
<p class="MsoPlainText"><b><span lang="EN-US" style="color:#1F497D">Emma: The draft \
currently aims to capitalize on IPsec for deriving keys for O/TWAMP. We will further \
edit the introductory text to address this point. <o:p></o:p></span></b></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">- [Abstract]<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">"it extends the applicability of \
O/TWAMP to networks that have already deployed IPsec"<o:p></o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US">"Unfortunately, however, standard IP \
performance measurement security mechanisms cannot be readily used with \
IPsec."<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">This gives the idea that you cannot use O/TWAMP with IPsec, but this is \
of course not true. You can e.g. send O/TWAMP over IPsec, and depending on the IPsec \
security policy database (SPD) you can send O/TWAMP outside of the IPsec \
tunnel.<o:p></o:p></span></p> <p class="MsoPlainText"><b><span lang="EN-US" \
style="color:#1F497D">Emma: Thanks for the comment. This was not our intention. \
Indeed O/TWAMP security and IPsec can be deployed and run separately. But given that \
the currently standardized O/TWAMP security mechanisms only support pre-shared key \
mode, large scale deployment and use is hindered significantly as mentioned in the \
draft. Deployment of "shared secrets" for massive equipment installation is not the \
best idea after all, I hope you agree with that. We will edit the text to address \
this.<o:p></o:p></span></b></p> <p class="MsoPlainText"><span lang="EN-US" \
style="color:#1F497D"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US">- [Section 1]<o:p></o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US">"In particular, we note that it is not \
necessary to use distinct keys in OWAMP-Control and OWAMP-Test layers. One key \
for encryption and another for authentication is sufficient for both Control and Test \
layers. This obviates the need to generate two keys for each layer and reduces \
the complexity of O/TWAMP protocols in an IPsec environment. This observation \
comes from the fact that separate session keys in the OWAMP-Control and OWAMP-Test \
layers were designed for preventing reflection attacks when employing the current \
mechanism."<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">I assume O/TWAMP uses different keys as is it bad security design to use \
the same key for two different purposes. Using the same key twice may leads a number \
of security problems<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">- It easily causes so called "two-time pads" were the \
confidentiality is totally compromised.<o:p></o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US">- For some algorithms the integrity may be \
compromised. <o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">- If one use of the keys has a \
cryptographic weakness so than an attacker can recover the key, the attacker has the \
use that key to attack both uses of the key.<o:p></o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US">- It gives an attacker twice as much material \
(protected traffic) to work with.<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">I therefore strongly recommends against using the same key twice unless \
you must, and in this case we do not.<o:p></o:p></span></p> <p \
class="MsoPlainText"><b><span lang="EN-US" style="color:#1F497D">Emma: Well, the \
draft does not exclude the use of distinct keys. Actually there are three options \
(basic + 2 alternatives) in the draft and we have already called for active \
discussion in the WG on which one is better, and we appreciate opening the technical \
discussion on this matter. The threats above can be considered when determining which \
option should be standardized.<o:p></o:p></span></b></p> <p \
class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US">- [Section 3.1]<o:p></o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US">The Server-Start message with Server-IV is \
missing from the text. <o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">Suggestion:<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">"In the authenticated and encrypted \
modes, all further communication is encrypted using the AES Session-key and \
authenticated with the HMAC Session-key. After receiving Set-Up-Response the \
server responds with a Server-Start message containing Server-IV. The client \
encrypts everything it transmits through the just-established O/TWAMP-Control \
connection using stream encryption with Client-IV as the IV." \
<o:p></o:p></span></p> <p class="MsoPlainText"><b><span lang="EN-US" \
style="color:#1F497D">Emma: OK with this suggestion.<o:p></o:p></span></b></p> <p \
class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US">- [Section 4]<o:p></o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US">I think "IPsec SA" is old \
terminology for IKE(v1), all occurrences should be changed to "Child \
SA".<o:p></o:p></span></p> <p class="MsoPlainText"><b><span lang="EN-US" \
style="color:#1F497D">Emma: OK with this suggestion.<o:p></o:p></span></b></p> <p \
class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US">- [Section 4]<o:p></o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US">"Therefore, even if the peers choose to \
opt for the unauthenticated mode, IPsec integrity protection is extended to \
O/TWAMP.<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">I think the document would be improved by discussing this and other \
options: <o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">O/TWAMP unauthenticated over existing \
Child SA with integrity.<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">O/TWAMP unauthenticated over existing Child SA with \
encryption.<o:p></o:p></span></p> <p class="MsoPlainText"><span lang="EN-US">O/TWAMP \
unauthenticated over existing Child SA with encryption and \
integrity.<o:p></o:p></span></p> <p class="MsoPlainText"><span lang="EN-US">O/TWAMP \
unauthenticated over new Child SA with encryption and or \
integrity.<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">in a separate section before the section on extracting keying material. \
It may very well be the case that O/TWAMP unauthenticated over the existing Child SA \
fulfills the user's security requirements.<o:p></o:p></span></p> <p \
class="MsoPlainText"><b><span lang="EN-US" style="color:#1F497D">Emma: The options \
listed above existed. But in this case, O/TWAMP layer should obtain the information \
about IPsec layer first (e.g. Child SA with integrity and/or encryption). The \
interaction between O/TWAMP layer and IPsec layer will \
increase.<o:p></o:p></span></b></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">- [Section 3.4]<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">"If the AH protocol is used, IP packets are transmitted in \
plaintext. The authentication part covers the entire packet. So all test \
information, such as UDP port number, and the test results will be visible to any \
attacker, which can intercept these test packets, and introduce errors or forge \
packets that may be injected during the transmission. In order to avoid this \
attack, the receiver must validate the integrity of these packets with the negotiated \
secret key."<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">As the packeges are authenticated an attacker cannot forge or inject \
errors. And as the packages are not encrypted, reading the information cannot \
be considered an attack.<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">I suggest deleting " to any attacker, which can intercept these \
test packets, and introduce errors or forge packets that may be injected during the \
transmission. In order to avoid this attack, the receiver must validate the \
integrity of these packets with the negotiated secret key. <o:p></o:p></span></p> <p \
class="MsoPlainText"><b><span lang="EN-US" style="color:#1F497D">Emma: OK with this \
suggestion.</span><span lang="EN-US"><o:p></o:p></span></b></p> <p \
class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US">- [Section 3.4, Section \
4]<o:p></o:p></span></p> <p class="MsoPlainText"><span lang="EN-US">"If ESP is \
used, IP packets are encrypted"<o:p></o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US">"When using ESP, all IP packets are \
encrypted"<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">This is not true as ESP can be used with only integrity protection (NULL \
cipher). In fact, I think this is far more common than using AH. Instead of start \
talking about AH, I think the draft could list the three different ESP options \
(integrity and/or encryption) and then have a note stating that for AH have similar \
properties as ESP with NULL cipher.<o:p></o:p></span></p> <p \
class="MsoPlainText"><b><span lang="EN-US" style="color:#1F497D">Emma: OK with this \
suggestion.<o:p></o:p></span></b></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">- [Section 4]<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">From a security perspective it would be very bad to allow extraction of \
SKEYSEED or KEYMAT. They could be used to passively eavesdrop on the IPsec traffic or \
to alter/inject messages. Even if we trust the O/TWAMP application to not be \
malicious, use of the same key in another application may cause security problems \
such as two-time pad, which completely compromises the \
confidentiality.<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">A secure solution would be that the IPsec API returns a key that is \
derived from some of IPsec keying material. E.g. a new "KEYMAT" derived \
using some new random material instead of (Ni,Nr), e.g.:<o:p></o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US">Shared secret = prf+( SK_d, SID ) <o:p> \
</o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">Or a key derived from KEYMAT: <o:p></o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US">Shared secret = PRF( KEYMAT, SID ) <o:p> \
</o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">I strongly suggest removing the options that exposes the IPsec keying \
material, only keeping secure options, and adding text describing that it is the \
IPsec implementation that performs the key derivations.<o:p></o:p></span></p> <p \
class="MsoPlainText"><b><span lang="EN-US" style="color:#1F497D">Emma: We agree that \
from a security pov deriving shared key at IPsec is a better choice. We can consider \
that in next version.<o:p></o:p></span></b></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">- [Section 4]<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">While extracting keying material from IPsec would be nice, to my \
knowledge there is no standardized (or de facto standard) API to extract SKEYSEED, \
SK_d, KEYMAT or even SPI from an IPsec implementation. This was even one of the \
reasons IPsec was not chosen as the default security protocol for O/TWAMP. You could \
of course do it with a new proprietary implementation, but that kind of beats some of \
the purpose from the Abstract "gaining popularity in several deployment \
scenarios".<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">Work on an IPsec API started a couple a years ago <a \
href="http://tools.ietf.org/html/draft-ietf-btns-ipsec-apireq-00">http://tools.ietf.org/html/draft-ietf-btns-ipsec-apireq-00</a><o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">but died, and even that work did prohibit \
extraction of keying material and discouraged the extraction of SPI as the SPI might \
change.<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">Has the API proposals been discussed in the ipsecme working \
group?<o:p></o:p></span></p> <p class="MsoPlainText"><b><span lang="EN-US" \
style="color:#1F497D">Emma: We received this comment at the last meeting (I think it \
was Yoav who commented on that). We believe that this is in fact \
implementation-dependent. For example, for those with existing IPsec and O/TWAMP \
implementations this should not be a blocking point. If there was a "standard" API, \
this protocol could benefit. But what we're interested primarily here is O/TWAMP \
deployment at large scale and for networks that have already deployed \
IPsec.<o:p></o:p></span></b></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">- [Section 4]<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">I think the approach in Section 4 with extracting keying material would \
only work with a proprietary IPsec implementation and modifications (adding new \
fields) to O/TWAMP.<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">Have approaches that do not require extracting keying information been \
considered?<o:p></o:p></span></p> <p class="MsoPlainText"><b><span lang="EN-US" \
style="color:#1F497D">Emma: I think we could discuss this in Vancouver. In the \
meantime, do you have text to suggest?<o:p></o:p></span></b></p> <p \
class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US">If the Child SA is encrypted, a simpler \
approach would be to transfer the O/TWAMP shared secret in a similar manner as the \
O/TWAMP session key, e.g. in the KeyID field. This would just require changes to the \
function in the O/TWAMP that receives the shared secret, and no modifications to \
IPsec.<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">At least if the Child SA is integrity protected, one approach would be \
to use Diffie-Hellman in O/TWAMP. This would still require new O/TWAMP fields but \
still be easier than the current suggestion as it does not require any changes to \
IPsec.<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">A problem is still the lack of API to find out whether encryption or \
integrity is in use. <o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">Minor editorial comments on \
draft-ietf-ippm-ipsec-01<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">------------------------------------------------------------------<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">- [s3.1] "OWAMP-Control \
commands" -> "O/TWAMP-Control commands"<o:p></o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US">- [s4] "must be generated firstly" \
-> "must be generated first"<o:p></o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US">- [s4] "session ID is is \
the"<o:p></o:p></span></p> <p class="MsoPlainText"><b><span lang="EN-US" \
style="color:#1F497D">Emma: OK with these editorial \
comments.<o:p></o:p></span></b></p> <p class="MsoPlainText"><span \
lang="EN-US"><o:p> </o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">------------------------------------------------------------------------------------<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">JOHN MATTSSON<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">MSc Engineering Physics, MSc Business \
Administration and Economics Senior Researcher, Security <o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">Ericsson AB<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">Security Research<o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US">F</span><span lang="EN-US" \
style="font-family:"Courier New"">ä</span><span lang="EN-US">r</span><span \
lang="EN-US" style="font-family:"Courier New"">ö</span><span \
lang="EN-US">gatan 6<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">SE-164 80 Stockholm, Sweden<o:p></o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US">Phone +46 10 71 43 \
501<o:p></o:p></span></p> <p class="MsoPlainText"><span lang="EN-US">SMS/MMS +46 \
76 11 53 501<o:p></o:p></span></p> <p class="MsoPlainText"><span \
lang="EN-US">john.mattsson at ericsson.com<o:p></o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US"><a href="http://www.ericsson.com"><span \
style="color:windowtext;text-decoration:none">www.ericsson.com</span></a><o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText"><span \
lang="EN-US">_______________________________________________<o:p></o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US">ippm mailing list<o:p></o:p></span></p> <p \
class="MsoPlainText"><span lang="EN-US"><a href="mailto:ippm@ietf.org"><span \
style="color:windowtext;text-decoration:none">ippm@ietf.org</span></a><o:p></o:p></span></p>
<p class="MsoPlainText"><span lang="EN-US"><a \
href="https://www.ietf.org/mailman/listinfo/ippm"><span \
style="color:windowtext;text-decoration:none">https://www.ietf.org/mailman/listinfo/ippm</span></a><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
</body>
</html>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--===============6152305281266035278==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic