Subject: [secdir] Security review of draft-ietf-ippm-ipsec-08

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 09 Feb 2015 07:45:21 +0100

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Summary: The specification proposes to derive keying material from an
IKEv2 exchange to secure the One-way Active Measurement Protocol (OWAMP)
[RFC4656] and the Two-Way Active Measurement Protocol (TWAMP) protocols.

Introduction:

In the introduction you point out that IKEv2 is very commonly deployed.
You even say that "In mobile telecommunication networks, the deployment
rate of IPsec exceeds 95% with respect to the LTE serving network."

While the exact number is probably not that important (and very likely
hard to verify) the statement does, however, raise some questions. You
seem to expect that you can re-use already deployed IKEv2 for the
special version of IKEv2 you are describing in this document and that's
unfortunately very unlikely to be true.

The solution described in the document requires a very tight integration
between an IKEv2 implementation (not IPsec) and the O/TWAMP application
and the text in the document gives me the impression that you are not
entirely aware that this will actually need to happen. This may lead to
unpleasant surprises when you implement it.

First, you will have to trigger the IKEv2 exchange from the application.
Second, you definitely do not want the IKEv2 exchange to create IPsec
SAs since you only want the outcome of the exchange to produce the
keying material as input to the O/TWAMP protocol via the already
standardized pre-shared authentication exchange. Third, when the IKEv2
exchange is finished it needs to notify the application that the keying
material is ready. The new key derivation function described in Section
5.1 is obviously not available in any IKEv2 implementation and, as you
correctly stated, you don't want to make export the SK_d directly to the
application but rather only the output of the derivation, namely prf(
SK_d, "IPPM" ). IMHO no off-the-shelf IKEv2
implementation will let applications access the SK_d directly nor will
it have an API to the IKEv2 SA either.

It might also want to think about potential interactions from the
IKEv2-> to O/TWAMP side, such as rekeying. I am not sure whether there
are issues to take into account but have you thought about them?

It might be wortwhile to talk to people who used IKEv2 in a way similar
to what you are proposing (namely for not establishing IPsec SAs). While
there may not be that many of such standardization development I
remember that there was some work in the routing area.

In Section 5.1 you describe a way to obtain for the O/TWAMP
implementation to interact with the IKEv2 code as follows:

"
   the IPSec layer can perform a lookup
   in the Security Association Database (SAD) using the IP address of
   the server and thus match the corresponding IKEv2 SA.  At the server
   side, the IPSec layer can look up the corresponding IKEv2 SA by using
   the SPIs sent by the client, and therefore extract the shared secret
"

I believe that this approach will not work since your use of IKEv2
shouldn't actually require any interaction with IPsec at all.

A small note on the use of shared secrets. It seems that you have the
impression that the shared secrets used in the O/TWAMP protocol have to
be manually configured. This may not necessarily be true if you want to
use them in cellular networks, as you describe.

I could imagine that a network management protocol could be used to
provision the shared secrets to the appropriate nodes. While public key
cryptography makes some aspects of the key distribution easier it does
raise other questions, such as distribution of trust anchors and the
question about authorization. Since you do not discuss authorization in
the document I am not sure it is of concern with the use of O/TWAMP.

I am not sure why you include the text in Section 5.4 where you describe
O/TWAMP over an IPsec tunnel since in the introduction you argue that
this is not an approach that you favour since it introduces delays into
the measurements.

I am also wondering whether this solution offers crypto agility. The
text describes that you use AES-CBC (for encryption) and HMAC-SHA1 (for
data origin authentication and integrity protection). IKEv2 could, of
course, allow you to negotiate other algorithms and particularly the
more modern AEAD ciphers.

In a few parts of the document you say "
   The new Modes value indicating support for this
   specification is IKEv2Derived and is equal to 128 (i.e. bit set in
   position 7) [NOTE to IANA: remove before allocation and final
publication]".

I am not sure what you are asking IANA to do. I believe what you are
trying to say is that you have proposed a specific value for this
extension and you want IANA to confirm that allocation. If IANA cannot
give you that value they should correct the text in the draft and put
the appropriate value there. If that's the case then the correct way to
write this is as follows:

"
   The new Modes value indicating support for this
   specification is IKEv2Derived and is TBD."

In the IANA consideration section you then note that all TBDs have to be
replaced with the value allocated by IANA.

I would also remove this paragraph in the Security Consideration section:

"
   As a more general note, the IPPM community may want to revisit the
   arguments listed in [RFC4656], Sec. 6.6.  Other widely-used Internet
   security mechanisms, such as TLS and DTLS, may also be considered for
   future use over and above of what is already specified in [RFC4656]
   [RFC5357].
"

While it is true that DTLS/TLS could also used (and are probably a
better choice) it feels like the wrong statement in this document. It
makes the reader feel like that even the authors are not convinced that
this is the right solution approach.

Ciao
Hannes

---

From: Kostas Pentikousis <[email-masked]>
Date: Thu, 12 Feb 2015 13:29:39 +0100

Hi Hannes,

<snip>

| comments were written primarily for the benefit of the security area
| directors.  Document editors and WG chairs should treat these comments just
| like any other last call comments.

Many thanks for the thorough review. Much appreciated.

<snip>

| In the introduction you point out that IKEv2 is very commonly deployed.
| You even say that "In mobile telecommunication networks, the deployment rate
| of IPsec exceeds 95% with respect to the LTE serving network."
| 
| While the exact number is probably not that important (and very likely hard to

This text originates from the motivation that got this draft going. In particular, the nearly 10-year old RFC 4656 argues in sec. 6.6 (https://tools.ietf.org/html/rfc4656#section-6.6), among other things, that 

     "The deployment paths of IPsec and OWAMP could be separate if OWAMP
      does not depend on IPsec.  After nine years of IPsec, only 0.05%
      of traffic on an advanced backbone network, such as Abilene, uses
      IPsec (for comparison purposes with encryption above layer 4, SSH
      use is at 2-4% and HTTPS use is at 0.2-0.6%).  It is desirable to
      be able to deploy OWAMP on as large a number of different
      platforms as possible."

I don't think we need to argue about the numbers for IPsec, HTTPS and so on today (esp. as we look towards 2020), but I would make the case that it's likely that IPsec is more widely deployed today than OWAMP is. Perhaps I'm wrong, please correct me. Hence, during the early phase of development of this draft we included this text to illustrate eminent use cases for this draft (such as the LTE case). If you think that "95%" should be replaced with "the vast majority of" or something of that nature, please let us know. If you have completely different numbers from operators, research studies or vendors for this type of deployment (or other settings for that matter), I'll be happy to hear them. 

| verify) the statement does, however, raise some questions. You seem to expect
| that you can re-use already deployed IKEv2 for the special version of IKEv2
| you are describing in this document and that's unfortunately very unlikely to
| be true.

I don't agree this is the case when I read the text.

| The solution described in the document requires a very tight integration
| between an IKEv2 implementation (not IPsec) and the O/TWAMP application and
| the text in the document gives me the impression that you are not entirely
| aware that this will actually need to happen. This may lead to unpleasant
| surprises when you implement it.

I don't agree with the term "very tight integration". In fact, we had the API discussion several times with folks in ipsecme over the last 2 years and a bit. I heard some of the background, and I agree that perhaps an IPsec vendor with *no interest in TWAMP* may have to think more if they want to invest the effort to support this spec. But for vendors with both implementations in house, I would leave it to their respective implementation teams. This spec would facilitate interoperability in this latter case.

As an aside, and given that this is an IPPM draft, I would like to point out that TWAMP per se (RFC 5357, sec. 1.2: https://tools.ietf.org/html/rfc5357#section-1.2) does leave certain interactions "unspecified", which "may be proprietary protocols".

| First, you will have to trigger the IKEv2 exchange from the application.
| Second, you definitely do not want the IKEv2 exchange to create IPsec SAs

<snip>

| "IPPM" ). IMHO no off-the-shelf IKEv2 implementation will let applications
| access the SK_d directly nor will it have an API to the IKEv2 SA either.

Agreed, wrt "off-the-shelf" (in general), after all this is not an RFC yet. But please see above.

| It might also want to think about potential interactions from the
| IKEv2-> to O/TWAMP side, such as rekeying. I am not sure whether there
| are issues to take into account but have you thought about them?

This is addressed in the last paragraph of sec. 5.1 (https://tools.ietf.org/html/draft-ietf-ippm-ipsec-09#section-5.1). If you would like other text to be added or this to be edited, please kindly send a proposal.

<snip>

| In Section 5.1 you describe a way to obtain for the O/TWAMP implementation to
| interact with the IKEv2 code as follows:
| 
| "
|    the IPSec layer can perform a lookup
|    in the Security Association Database (SAD) using the IP address of
|    the server and thus match the corresponding IKEv2 SA.  At the server
|    side, the IPSec layer can look up the corresponding IKEv2 SA by using
|    the SPIs sent by the client, and therefore extract the shared secret "
| 
| I believe that this approach will not work since your use of IKEv2 shouldn't
| actually require any interaction with IPsec at all.

We use IPsec to refer to IKE+ESP/AH in this draft. If you would like to propose alternative, better refined text, please let us know.

<snip>

| I could imagine that a network management protocol could be used to provision
| the shared secrets to the appropriate nodes. While public key cryptography
| makes some aspects of the key distribution easier it does raise other
| questions, such as distribution of trust anchors and the question about
| authorization. Since you do not discuss authorization in the document I am not
| sure it is of concern with the use of O/TWAMP.

Indeed, a network management protocol _could_ be used, but this is not standardized and, imo, orthogonal to the problem at hand. Perhaps we should start a separate draft for OAM-based shared secret distribution for TWAMP.

| I am not sure why you include the text in Section 5.4 where you describe
| O/TWAMP over an IPsec tunnel since in the introduction you argue that this is
| not an approach that you favour since it introduces delays into the
| measurements.

This was introduced as part of the consensus process in the WG. If your comment is editorial in nature, then [editor hat on] I would let it go [editor hat off]. If it's substantial, blocking, then I would be happy to remove sec. 5.4. Mind you, several parts of the draft have been repeatedly tuned to reach consensus over the last 2 years.

| I am also wondering whether this solution offers crypto agility. The text
| describes that you use AES-CBC (for encryption) and HMAC-SHA1 (for data origin
| authentication and integrity protection). IKEv2 could, of course, allow you to
| negotiate other algorithms and particularly the more modern AEAD ciphers.

AES-CBC and HMAC-SHA1 are algorithms defined in the O/TWAMP RFCs. Perhaps there is space for another draft in this direction as well, i.e. to allow for more crypto agility in TWAMP beyond has been standardized so far.

| In a few parts of the document you say "
|    The new Modes value indicating support for this
|    specification is IKEv2Derived and is equal to 128 (i.e. bit set in
|    position 7) [NOTE to IANA: remove before allocation and final
| publication]".
| 
| I am not sure what you are asking IANA to do. I believe what you are trying to
| say is that you have proposed a specific value for this extension and you want
| IANA to confirm that allocation.

<snip>

Done in -09

| I would also remove this paragraph in the Security Consideration section:
| 
| 
| "
|    As a more general note, the IPPM community may want to revisit the
|    arguments listed in [RFC4656], Sec. 6.6.  Other widely-used Internet
|    security mechanisms, such as TLS and DTLS, may also be considered for
|    future use over and above of what is already specified in [RFC4656]
|    [RFC5357].
| "
| 
| While it is true that DTLS/TLS could also used (and are probably a better
| choice) it feels like the wrong statement in this document. It makes the
| reader feel like that even the authors are not convinced that this is the
| right solution approach.

We have removed this paragraph in -09, as per your request: http://www.ietf.org/rfcdiff?url1=draft-ietf-ippm-ipsec-08&url2=draft-ietf-ippm-ipsec-09. However, this brings us back to motivation discussion at the beginning of this email.

Once again, many thanks.

Best regards,

Kostas