Re: [IPsec] secdir review of draft-ietf-lwig-minimal-esp-03

[David Mandelberg <[e-mail]>]

Thanks for the updates and clarification!

Op 31-03-2021 om 08:46 schreef Daniel Migault:
> Hi David,
> 
> Thanks the review. I think the text  in [1] addresses your concern. I will probably publish the a new version today. Please see my responses inline.
> 
> Yours,
> Daniel
> 
> [1] https://github.com/mglt/draft-mglt-lwig-minimal-esp/pull/1/commits/fb9393a246298e37adcf2683afa2061a40b4ed89
> 
> -----Original Message-----
> From: David Mandelberg <[e-mail]>
> Sent: Saturday, March 27, 2021 5:39 PM
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: secdir review of draft-ietf-lwig-minimal-esp-03
> 
> 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.
> 
> The summary of the review is Ready with nits.
> 
> (Section 3, nit) In the paragraph that includes "However, nonrandom SPI and restricting their possible values MAY lead to privacy and security concerns" , it would be nice to add something like "(see below for more details)". When I first read that paragraph, I was about to comment that it's unclear what the privacy/security concerns are, but then it was explained a few paragraphs below.
> 
> <mglt>
> That is correct, we restructured a bit the section to clarify this by having a subsection dedicated to considerations over the generation of SPIs.
> 
> The current section is available at [1] and is mentioned below:
> [1] https://github.com/mglt/draft-mglt-lwig-minimal-esp/pull/1/commits/fb9393a246298e37adcf2683afa2061a40b4ed89
> 
> <section title="Considerations over SPI generation">
> 
> <t>SPI that are not randomly generated over 32 bits MAY lead to privacy and security concerns.
> As a result, the use of alternative designs requires careful security and privacy reviews.
> This section provides some considerations upon the adoption of alternative designs. </t>
> 
> <t>Note that SPI value is used only for inbound traffic, as such the SPI negotiated with IKEv2 <xref target="RFC7296"/> or <xref target="RFC7815"/> by a peer, is the value used by the remote peer when it sends traffic.
> As SPI is only used for inbound traffic by the peer, this allows each peer to manage the set of SPIs used for its inbound traffic.
> Similarly, the privacy concerns associated with the generation of nonrandom SPI is also limited to the incoming traffic.</t>
> 
> <t>When alternate designs are considered, it is likely that the number of possible SPIs will be limited.
> This limit should both consider the number of inbound SAs - possibly per IP addresses - as well as the ability for the node to rekey.
> SPI can typically be used to proceed to clean key update and the SPI value may be used to indicate which key is being used.
> This can typically be implemented by a SPI being encoded with the Security Association Database (SAD) entry on a subset of bytes (for example 3 bytes), while the remaining byte is left to indicate the rekey index.
> </t>
> 
> 
> <t>The use of a smaller number of SPIs across communications comes with privacy and security concerns.
> Typically some specific values or subset of SPI values may reveal the models or manufacturer of the node implementing ESP.
> This may raise some privacy issues as an observer is likely to be able to determine the constrained devices of the network.
> In some cases, these nodes may host a very limited number of applications - typically a single application - in which case the SPI would provide some information related to the application of the user.
> In addition, the device or application may be associated with some vulnerabilities, in which case specific SPI values may be used by an attacker to discover vulnerabilities.
> </t>
> 
> <t>
> While the use of randomly generated SPI may reduce the leakage or privacy or security related information by ESP itself, these information may also be leaked otherwise and a privacy analysis should consider at least the type of information as well the traffic pattern.
> Typically, temperature sensors, wind sensors, used outdoors do not leak privacy sensitive information and mosty of its traffic is expected to be outbound traffic.
> When used indoors, a sensor that reports every minute an encrypted status of the door (closed or opened) leaks truly little privacy sensitive information outside the local network. </t>
> 
> 
> 
> </section>
> </mglt>
> 
> (Section 4) Am I understanding correctly, that the last paragraph is giving the option of resetting the Sequence Number when rekeying? Does IPSec try to prevent eavesdroppers from determining when rekeying happens? (I really don't know that much about IPSec.) If it does, then resetting the SN could leak that information, if not then there's nothing to leak.
> 
> <mglt>
> No. The last sentence of the section intended to prevent implementers to only consider the SN to define the life time of their SA. If implementer choose to use ESN for that purpose, it might be a good indication that a re-key mechanism is needed.
> 
> The current text has been updated to clarify this by the following text:
> 
> """
> Note that the limit of messages being sent is primarily determined by the security associated with the key rather than the SN.
> The security of all data protected under a given key decreases slightly with each message and a node MUST ensure the limit is not reached - even though the SN would permit it.
> Estimation of the maximum number of packets to be sent by a node is always challenging and as such should be considered cautiously as nodes could be online for much more time than expected.
> Even for constrained devices, it is RECOMMENDED to implement some rekey mechanisms (see <xref target="sec-security-considerations"/>).
> """
> 
> Regarding IPsec, a rekey leads to the creation of a new SA, so if you do not want to leak the information you may create the new SA in advance and only use it later. However, the creation is performed via an IKEv2 exchange which is not a very busy channel. As a result, exchanges performed on this channel are potential rekey exchanges. As result, it seems to me a bit hard to hide when a rekey occurs.
> SN do not have to be reset to 0. The only requirement is to increase these SN for each packet. On the other hand, this make it possible to maintain the SN number keep growing while SPI and keys are updated... until you reach the end.
> 
> If you need to keep the same SPI, you may delete the SA first before starting a new negotiation, this would enable you to re-use the same SPI.
> </mglt>
>