Re: [ippm] draft-ietf-ippm-ipsec-01 review

["Zhanglijia (A)" <[e-mail]>]

Hi all,



The previous email was held since message body is too big(>50KB) and awaited moderator approval. So I edit the email and resent it. Hoping it will work.



Best Regards

Emma
发件人: [e-mail] [mailto:[e-mail]] 代表 Zhanglijia (A)
发送时间: 2013年11月1日 15:29
收件人: John Mattsson
抄送: [e-mail]; [e-mail]
主题: Re: [IPsec] draft-ietf-ippm-ipsec-01 review


Hi John, all



Many thanks for the review! Please see the reply as bellow.



Best Regards

Emma

-----邮件原件-----
发件人: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] 代表 John Mattsson
发送时间: 2013年10月23日 5:37
收件人: [e-mail]<mailto:[e-mail]>
主题: [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