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

[John Mattsson <[e-mail]>]

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? 

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

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

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

- [Section 4]
I think "IPsec SA" is old terminology for IKE(v1), all occurrences should be changed to "Child SA".

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

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

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

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

- [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?

- [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?

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"


------------------------------------------------------------------------------------
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 [phone]
SMS/MMS [phone]
john.mattsson at ericsson.com
www.ericsson.com