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 <da...@mandelberg.org>
Sent: Saturday, March 27, 2021 5:39 PM
To: i...@ietf.org; sec...@ietf.org; draft-ietf-lwig-minimal-esp....@ietf.org
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>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
