<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
     <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
     <!ENTITY RFC7296 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7296.xml">
     <!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
     <!ENTITY RFC8229 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8229.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc ipr="trust200902"
    updates=""
    obsoletes=""
    category="std"
    docName="draft-dschinazi-ipsecme-sa-init-privacy-addition-00">

<!-- category values: std, bcp, info, exp, and historic -->

<!-- ***** FRONT MATTER ***** -->

<front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
         full title is longer than 39 characters -->

    <title abbrev="IKEv2 IKE_SA_INIT Privacy Addition">Privacy Addition to the Internet Key Exchange Protocol Version 2 (IKEv2) IKE_SA_INIT Exchange</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->


    <author fullname="David Schinazi" initials="D." surname="Schinazi">
        <organization>Apple Inc.</organization>
        <address>
            <postal>
                <street>1 Infinite Loop</street>
                <city>Cupertino</city>
                <region>California</region>
                <code>95014</code>
                <country>US</country>
            </postal>
            <phone></phone>
            <email>dschinazi@apple.com</email>
        </address>
    </author>

    <date/>

    <area>Security</area>
    <workgroup>ipsecme</workgroup>

    <!-- TODO
    -->

    <abstract>
        <t>The Internet Key Exchange Protocol version 2 (IKEv2) provides strong security and privacy properties to both endpoints once they have authenticated each other. However, before an endpoint has validated the peer's AUTH payload, it could be divulging information to an untrusted host. An example of such information is the Identification payload of the initiator. Another example is the fact that a host is running an IKEv2 responder. This document introduces a new "Initialization Authentication Code" notify payload that can be included in IKE_SA_INIT messages to increase their trustworthiness. This new protection is meant to be used in addition to current IKEv2 mechanisms and is not meant to replace the AUTH payload in any way.</t>
    </abstract>
</front>

<middle>
    <?rfc needLines="40"?>
    <section title="Introduction">
        <t>The Internet Key Exchange Protocol version 2 (IKEv2) <xref target="RFC7296"/> provides strong security and privacy properties to both endpoints once they have authenticated each other. However, before an endpoint has validated the peer's AUTH payload, it could be divulging information to an untrusted host. Examples include:
            <list style="symbols">
                <t>The Identification payload of the initiator is sent with the initiator's first IKE_AUTH request. This payload can be used to track the owner of the device initiating IKE.</t>
                <t>Some IKEv2 servers may wish to hide their very existence to avoid being blacklisted by entities that resent the privacy properties an IKEv2/IPsec tunnel can provide to users. If the IKEv2 server is accessible over TLS on a TCP port <xref target="RFC8229"/> that is shared with another protocol, responding to the initiator's IKE_SA_INIT can disclose the server's existence.</t>
            </list>
        </t>
        <t>This document introduces a new "Initialization Authentication Code" (IAC) notify payload that can be included in IKE_SA_INIT messages to increase their trustworthiness. This new protection is meant to be used in addition to current IKEv2 mechanisms and is not meant to replace the AUTH payload in any way.</t>
        <section title="Requirements Language">
            <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>
        </section>
        <section title="Terminology">
            <t>This document uses the following terms:
                <list style="hanging" hangIndent="10">
                    <t hangText="Endpoint">One of the two hosts that are involved in an IKE exchange.</t>
                    <t hangText="Initiator">The endpoint that sends the first IKE_SA_INIT request of the IKE exchange being discussed.</t>
                    <t hangText="Responder">The endpoint that is not the initiator.</t>
                    <t hangText="Peer">When discussing an endpoint, its peer is the other endpoint participating in the IKE exchange.</t>
                    <t hangText="IASS">Initialization Authentication Shared Secret, a shared secret included in the IKEv2 configuration. It is separate from any shared secret used for computation of the AUTH payload.</t>
                    <t hangText="MAC">Message Authentication Code, a cryptographic means of ensuring integrity and authenticity of a message.</t>
                    <t hangText="IAC">Initialization Authentication Code, a MAC of IKE_SA_INIT nonces with the IASS.</t>
                    <t hangText="PRF">Pseudo-Random Function, a function used to compute the IAC.</t>
                </list>
            </t>
        </section>
    </section>

    <section anchor="attack_vector" title="Attack Vectors">
        <t>This document only attempts to address the following attack vectors.</t>
        <section anchor="attack_vector_ini" title="On-Path Attacker Targeting Initiator">
            <t>This attack vector assumes the presence of an active on-path attacker that can block and forge any packets between both endpoints. Without the mechanism described in this document, the attacker can forge an IKE_SA_INIT reply and get the initiator to send it its IKE_AUTH request encrypted with the ephemeral shared secret computed between the initiator and the attacker. This leaks the identity of the initiator (IDi) and can leak the identity of the responder (IDr) if the initiator also sent it.</t>
        </section>
        <section anchor="attack_vector_resp" title="Off-Path Attacker Targeting Responder">
            <t>Some network middleboxes may wish block to block IKEv2 negotiation. This is often done by blocking UDP traffic which can be worked around using IKEv2 TCP encapsulation <xref target="RFC8229"/>. This obfuscation can even be improved by encapsulating IKEv2 and IPsec inside TLS. However, a more persevering middlebox can establish a TLS connection to the responder and try to send an IKE_SA_INIT to probe the server for IKEv2 support. Without the mechanism described in this document, the responder has to send an IKE_SA_INIT reply before it's established any initiator identity, leaking the presence of the IKEv2 server.</t>
            <?rfc needLines="20"?>
        </section>
    </section>

    <section anchor="initauth" title="Initialization Authentication">
        <section anchor="computeinitauth" title="Computing Initialization Authentication">
            <t>Each endpoint configuration will include both an IASS and a PRF for this endpoint, and also IASS and PRF of the peer. It will commonly be the case (but it is not required) that the same IASS and the same PRF is used in both directions.</t>
            <t>The peers authenticate the IKE_SA_INIT messages by having each MAC nonces using a padded shared secret as the key. The IAC is computed as follows:</t>
            <t>IAC_i = prf_i( prf_i(IASS_i, "Initialization Authentication Key Pad for IKEv2 Initiator"), Ni)</t>
            <t>IAC_r = prf_r( prf_r(IASS_r, "Initialization Authentication Key Pad for IKEv2 Responder"), Ni | Nr)</t>
            <t>Where IAC_i and IAC_r are the Initialization Authentication Codes of the initiator and responder respectively. Ni and Nr are the nonces sent in the IKE_SA_INIT messages that contain the IAC. The strings are 57 ASCII characters without null termination. prf_i() and prf_r() denote the PRFs selected in the initiator and responder configurations respectively. IASS_i and IASS_r denote the initialization authentication shared secret in the initiator and responder configurations respectively.</t>
            <t>The pad strings are added so that if the IASS are derived from a password, the IKE implementation need not store the password in cleartext, which could not be used as a password equivalent for protocols other than IKEv2. Using different pad strings for each direction limits the information leakage about the IASS if IASS_i and IASS_r are equal. IAC_r is based on both Ni and Nr to prevent replay attacks on the IKE_SA_INIT reply while also preventing a MAC oracle on the responder, since the responder controls the random generation of Nr.</t>

<!--

                In these calculations, IDi' and IDr' are the entire ID
   payloads excluding the fixed header.  For the responder, the octets
   to be signed start with the first octet of the first SPI in the
   header of the second message (IKE_SA_INIT response) and end with the
   last octet of the last payload in the second message.  Appended to
   this (for the purposes of computing the signature) are the
   initiator's nonce Ni (just the value, not the payload containing it),
   and the value prf(SK_pr, IDr').  Note that neither the nonce Ni nor
   the value prf(SK_pr, IDr') are transmitted.  Similarly, the initiator
   signs the first message (IKE_SA_INIT request), starting with the
   first octet of the first SPI in the header and ending with the last
   octet of the last payload.  Appended to this (for purposes of
   computing the signature) are the responder's nonce Nr, and the value
   prf(SK_pi, IDi').  It is critical to the security of the exchange
   that each side sign the other side's nonce.</t>

   The initiator's signed octets can be described as:

   InitiatorSignedOctets = RealMessage1
   GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
   RealIKEHDR =  SPIi | SPIr |  . . . | Length
   RealMessage1 = RealIKEHDR | RestOfMessage1



   The responder's signed octets can be described as:

   ResponderSignedOctets = RealMessage2 | NonceIData
   GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
   RealIKEHDR =  SPIi | SPIr |  . . . | Length
   RealMessage2 = RealIKEHDR | RestOfMessage2
   NonceIPayload = PayloadHeader | NonceIData

   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Algo. Transform ID  |           RESERVED            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~              Initialization Authentication Data               ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


-->
    <?rfc needLines="20"?>
        </section>
        <section anchor="initauthpayload" title="Initialization Authentication Notify Payload">
            <t>The Initialization Authentication Notify Payload is defined as follows:
                <figure><artwork><![CDATA[
                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) |   Notify Message Type (=TBD)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~              Initialization Authentication Code               ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure></t>
        <t>The 'Next Payload', 'C', 'RESERVED', 'Payload Length', 'Protocol ID', 'SPI Size', and 'Notify Message Type' fields are the same as described in Section 3 of <xref target="RFC7296"/>. The Critical ('C') bit MUST be set to 0. The 'SPI Size' field MUST be set to 0 to indicate that the SPI is not present in this message. The 'Protocol ID' MUST be set to 0, since the notification is specific to this IKE_SA_INIT message. The 'Payload Length' field is set to the length in octets of the entire payload, including the generic payload header. The 'Notify Message Type' field is set to indicate INITIALIZATION_AUTHENTICATION_CODE (TBD). The Initialization Authentication Code field has a variable length, and is computed according to <xref target="computeinitauth"/>.</t>
<!--
        <t><list style="symbols">
            <t>Integrity Algorithm Transform ID (2 octets) - Specifies the integrity algorithm used to compute the initialization authentication code. The list of possible values is maintained in the IANA registry for IKEv2 integrity (type 3) algorithm transform identifiers <xref target="IKEV2IANA"/>.</t>
            <t>RESERVED (2 octets) - MUST be sent as zero; MUST be ignored on receipt.</t>
            <t>Initialization Authentication Code (variable length) - see <xref target="computeinitauth"/>.</t>
        </list></t>
-->
        </section>
        <section anchor="recvinitauth" title="Receiving Initialization Authentication">
            <t>When the responder receives the initiator's IKE_SA_INIT request, it has not yet established the identity of the initiator, as the identity payload will come later. If the responder has distributed the same initialization authentication shared secret for all of its clients, it can easily verify that incoming IKE_SA_INIT requests come from clients that possess the shared secret. If the responder uses different initialization authentication shared secrets per client, it will have to iterate all of them to find a match since there is no identity sent with the IKE_SA_INIT request. Care should be taken with regards to the timing of the IKE_SA_INIT reply to avoid leaking information. If the responder cannot find a (IASS, PRF) combination in its configuration that matches the IAC in the incoming IKE_SA_INIT request, it MUST silently ignore the incoming packet. Not responding at all is crucial to hiding the fact that the responder is running an IKEv2 server. The responder SHOULD log the failure to facilitate debugging.</t>
            <t>When the initiator receives the responder's IKE_SA_INIT reply, it knows the identity of the responder it is trying to establish a security association with. It can therefore use the (IASS, PRF) from its configuration to validate the IAC on the reply. If the IAC in the reply does not match what was computed from the configuration, the initiator treats this similarly to receiving and error on the reply and MUST fail the exchange and MUST NOT send the IKE_AUTH message it would have normally sent. This is crucial to protect the initiator identity (IDi) from an active on-path attacker. The initiator SHOULD log the failure to facilitate debugging.</t>
        </section>
    </section>

    <section anchor="security" title="Security Considerations">
        <t>This document attempts to resolve the attacks described in <xref target="attack_vector"/> and no other attacks on IKEv2.</t>
            <section anchor="timing" title="Timing Attacks">
                <t>An IKEv2 responder wishing to stay hidden needs to ensure it doesn't leak information via the timing of its responses. In general if it receives an IKE_SA_INIT message whose IAC does not match, it simply does not respond. However if IKEv2 is running over TCP, the timing of when the responder closes the TCP connection can leak information. Implementors of hidden IKEv2 responders should ensure that they reply to bad input and to invalid IAC in similar time. In particular, if the server is also running another application protocol on the same port, it SHOULD reply to an invalid or missing IAC the same way as it would reply to an invalid request on that other protocol.</t>
            </section>

            <section anchor="replay" title="Replay Attacks">
                <t>The initiator's IKE_SA_INIT message is sent unencrypted and can be replayed. The mechanism described in this document is still vulnerable to replays of the IKE_SA_INIT message. Note however that an obfuscated IKEv2 server running over TLS can leverage TLS to ensure the absence of on-path attackers inside the TLS channel between both endpoints.</t>
                <t>The responder's IKE_SA_INIT message is also sent unencrypted and can also be replayed. However, the Initialization Authentication Code takes Ni as input so replaying a previous responder IKE_SA_INIT for a different IKEv2 exchange will have a different IAC and will be ignored.</t>
            </section>

            <section anchor="dos" title="Denial of Service Attacks">
                <t>An IKEv2 responder implementing this specification opens themselves to computing more MACs for IKE_SA_INIT messages. We believe that downside is negligible compared to other DOS attacks on IKEv2.</t>
            </section>
    </section>
<!--
Next Payload Type                Notation  Value
Initialization Authentication    IA        TBD
-->
    <section anchor="iana" title="IANA Considerations">
        <t>If approved, this document defines a new payload in the IANA "IKEv2 Notify Message Types - Status Types" registry <xref target="IKEV2IANA"/>:
            <figure><artwork><![CDATA[
    NOTIFY messages: status types            Value
    -----------------------------------------------------------------
    INITIALIZATION_AUTHENTICATION_CODE       TBD
]]></artwork></figure></t>
    </section>
<!--
    <section anchor="acknowledgments" title="Acknowledgments">
        <t>TODO</t>
    </section>
-->
</middle>

<back>
    <references title="Normative References">
        &RFC2119;
        &RFC7296;
        &RFC8174;
        &RFC8229;

        <reference anchor='IKEV2IANA' target='https://www.iana.org/assignments/ikev2-parameters/' >
            <front>
                <title>IANA, Internet Key Exchange Version 2 (IKEv2) Parameters</title>
                <author/>
                <date/>
            </front>
        </reference>
    </references>

<!--
    <references title="Informative References">
    </references>
-->
    <?rfc needLines="10"?>
</back>
</rfc>
