Subject: Re: [ippm] I-D Action: draft-ietf-ippm-ipsec-02.txt

From: John Mattsson <[email-masked]>
Date: Mon, 3 Mar 2014 00:04:34 +0000

The security problems seem to have been fixed and the draft is now much clearer.

Some comments:

- [General]
I think the list (in this case Alfred Morton and me) was quite clear on that unauthenticated *WAMP through an IPsec tunnel was an attractive solution that should be better described. As explained by Alfred Morton:

“I'll keep reading, but I'm beginning to wonder if setting up an IPsec tunnel and setting up *WAMP Control and Test protocols to transfer through the tunnel (unauthenticated so as not to waste processing on redundant security) is the solution?  But what about the deployment of IPsec in LTE networks: If a tunnel is established automatically for any data transfer, the *WAMP could be viewed as typical user traffic inside an existing tunnel.”

While this is now mentioned shortly in the introduction, the text sections describing the security properties when sending *WAMP over AH or ESP has instead been removed. These should be reinstated, preferably in a separate subsection in section 4.

- [Section 4.1]
“ The shared secret key can be generated as follows:

      Shared secret key = PRF{ SKEYSEED, "IPPM" }
“

Even if the IPsec APIs are proprietary, I do not think that the key derivation can be in a draft that aims to be standard track.

Unless the key derivation is defined, different implementations won’t be compatible.

Encoding of “IPPM” should probably be defined.

You probably mean prf() (with ordinary brackets)

- [General]
I cannot see that the draft mentions the case when both client and server supports IKEv2 but there is no current IKE SA.

- [Section 1]
Maybe a explanation or reference to eNB and SeGW

Thanks,

John

JOHN MATTSSON
MSc Engineering Physics, MSc Business Administration and Economics
Ericsson IETF Security Coordinator
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
[email-masked]<mailto:[email-masked]>
www.ericsson.com<http://www.ericsson.com/>

---

From: "Zhanglijia (A)" <[email-masked]>
Date: Mon, 3 Mar 2014 10:54:45 +0000

Hi John,

Many thanks for your comments. Please see the reply as bellow.

Best regards,
Emma

发件人: ippm [mailto:[email-masked]] 代表 John Mattsson
发送时间: 2014年3月3日 8:05
收件人: [email-masked]<mailto:[email-masked]>
主题: Re: [ippm] I-D Action: draft-ietf-ippm-ipsec-02.txt

Some comments:

- [General]

While this is now mentioned shortly in the introduction, the text sections describing the security properties when sending *WAMP over AH or ESP has instead been removed. These should be reinstated, preferably in a separate subsection in section 4.
 [Emma]: I agree that unauthenticated *WAMP through an IPsec tunnel can be one option. However, as we mentioned before, the draft mainly focuses on how to derive shared key from IKE SA to achieve automatic key management and how to extend *WAMP protocol to support that. So this is mentioned shortly in the draft. We can consider to add some text about it in next version.
- [Section 4.1]
“ The shared secret key can be generated as follows:

You probably mean prf() (with ordinary brackets)
  [Emma]: Thanks for this comment. Yes, it means prf() (with ordinary brackets) and the string "IPPM" are ASCII characters.

- [General]
I cannot see that the draft mentions the case when both client and server supports IKEv2 but there is no current IKE SA.
  [Emma]: Two alternative ways in above case:
a. IP layer in the client initiates to establish IKE SA for IPPM application, then the client choose the mode which support IKEv2
b. IP layer in the client does not initiate to establish IKE SA and responds error code to IPPM application, then the client choose the mode defined in RFC 4656.
Both alternatives are feasible. In my opinion, it belongs to interaction between IP layer and IPPM application layer and it also can be proprietary.
This use case will be considered in next version.

- [Section 1]
Maybe a explanation or reference to eNB and SeGW
  [Emma]: Both eNB and SeGW support certificate mode and IKEv2. Provision of shared secret for them will waste time and add complexity<javascript:void(0)>. Deriving shared key from IKE SA is fit for the use case like that.

Thanks,

John

JOHN MATTSSON

Ericsson AB
Security Research
Färögatan 6