[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
problems with draft-jenkins-ipsec-rekeying-06.txt
This document describes a number of substantive problems we perceive with
draft-jenkins-ipsec-rekeying-06.txt. We don't think this draft is ready
to be an RFC, even an Informational one. We see significant problems in
both the description and the intent. (We apologize for leaving this to
the last minute, but much of this became clear to us only recently.)
| 2.2.1.4 Responder Pre-Set-up Security Hole
|
| In the failed negotiation case, the need to delete the invalid
| inbound SA raises the issue of a temporary hole, in that the
| responder allows inbound packets while waiting for the third quick
| mode message. However, if the inbound SA is not set up ahead of
| time, initiators that immediately transmit on the new outbound SA
| will cause packets to be dropped.
We don't see why this is a security hole. The Responder has set up an
inbound IPSEC SA because the Initiator has made a request to do so.
The request is authenticated and the protection suite has been
selected. This seems adequately secure.
| It also illustrates why the proposal above made the usage of the
| outbound SA by the initiator wait until there is an indication of
| the use of the SA by the responder.
This isn't required because the responder could set up the SA earlier.
| Note that this security hole is exactly what would result from an
| attacker replaying the first quick mode message of an exchange.
A replay attack cannot succeed since the RFCs require that the Message
ID be unique. The Message ID is protected by encryption and
authenticated by being included in HASH(1).
| 2.2.2 Recommended Re-keying Method
| 2.2.2.2 Absence of Traffic
| However, due to the number of implementations that delete old SAs 30
| seconds after negotiating a new one, the same behaviour has the best
| chance of interoperability, and of not dropping packets when traffic
| does restart.
|
| Therefore, it is recommended that implementations delete old SAs and
| start using new SAs 30 seconds after negotiating new SAs in the
| absence of traffic. Use of the DELETE notification is strongly
| recommended in cases where the peer implementation is continuing to
| use the old SA.
It would surely aid interoperability to leave the the inbound SA for a
longer time. This is true even if the DELETE notification is sent --
it can be lost or ignored.
There are other reasons to delete the inbound SA, and they may point
to a recommendation for deletion, but the reason given here does not
apply.
| 3.4.2 INITIAL-CONTACT Notification
|
| As stated above, the INITIAL-CONTACT notification should be used
| only with the very first phase 1 SA that is negotiated between two
| peers.
We think that INITIAL-CONTACT is a useful mechanism, but there are
flaws.
- There are well-known problems with the integrity of Informational
Payloads. Within a Main Mode exchange, they are not authenticated.
The consequences of acting on a forged INITIAL-CONTACT are severe.
- the meaning of INITIAL-CONTACT is not sufficiently nailed down in
rfc2407.txt:
"The INITIAL-CONTACT status message may be used when one side wishes
to inform the other that this is the first SA being established with
the remote system."
+ the meaning of "system" is not given.
* Are systems identified with IP addresses?
(in reality, a system might have several IP addresses)
* Do/should Phase 1 IDs play any part in this?
(It might be that the authority to blow away other SAs
should be limited to SAs that have the same ID, the basis
for authentication.)
+ Observations on one system may be ordered differently from
observations on another. So the word "first", upon which the
meaning of INITIAL-CONTACT crucially depends, is not defined in a
way that both will always agree. This is exacerbated because
INITIAL-CONTACT should be delayed until a Quick Mode negotiation,
so it can be authenticated and hence trustworthy.
(We actually think that a FINAL-CONTACT message would be useful, given a
precise definition. Interestingly, we think that INITIAL-CONTACT might be
usable for this purpose! After all, it would probably cause all but one
SA to be deleted; it might prompt the recipient to renegotiate SAs, but
the sender could refuse to negotiate.)
| If used on subsequent negotiations, it means that all pre-existing
| SAs (phase 1 and phase 2) held between the peers should be deleted.
It is interesting to note that INITIAL-CONTACT is only defined in the
IPSEC-DOI. This seems like an oversight to us. This could be a
problem because a Main Mode SA proposal could specify a DOI of 0.
This document should require that IPSEC-DOI be specified.
| As an example, this is the mechanism used to detect when an SA end
| point has crashed and is now alive again.
|
| The use of INITIAL-CONTACT may be restricted by the mode used to
| negotiate phase 1 SAs. For these reasons, implementations may want
| to avoid the use of aggressive mode when possible. When it is used,
| it is recommended that the third aggressive mode message be
| encrypted so that the INITIAL-CONTACT notification can be added to
| it when needed. Note that the use of any notification by a responder
| during aggressive mode is not allowed, and this document's
| suggestion that the use of INITIAL-CONTACT is permitted by the
| initiator if the third aggressive mode packet is encrypted is
| possibly contrary to RFC2408.
|
| Alternatively, if notifications cannot be used within the phase 1
| modes at all, it is recommended that INITIAL-CONTACT be sent in a
| notification packet (preferably acknowledged) immediately after the
| phase 1 is complete. Reception of this notification (at any time)
| should indicate to the receiver that all other SAs, phase 1 and
| phase 2, with the sender must be deleted. (In other words, the SA
| that was used to encrypt the notification is the only SA that is not
| deleted.)
The only safe places to put INITIAL-CONTACT that are RFC-compliant are in
the first two messages of a Quick Mode Exchange. Elsewhere they are not
authenticated, cannot be trusted, and *must be ignored*.
| 3.4.1 Multiple SA Usage
^ISAKMP
|
| When there is more than one phase 1 SA between peers,
What is the definition of "peers" being used here? Not all ISAKMP SAs
are interchangeable. Some have different protection suites. Some
have different Phase 1 ID authentication.
| it is
| recommended that the oldest SA be used for subsequent traffic
| requiring phase 1 SAs.
We have found that always using the newest ISAKMP SA avoids some
problems when a system is restarted. INITIAL-CONTACT addresses some
of the same problems, but it is optional, ill-defined, inconsistently
used, and less timely.
| This allows full use of the keying material
| generated
We don't understand this to be an issue. Surely if a new ISAKMP SA is
negotiated, it was negotiated for some reason. If the reason is that
it was time to rekey, then the keying material is close to expired --
discarding the old ISAKMP SA wastes little. If it was another reason,
this rule may stymie the intent.
| and reduces race conditions.
Which race conditions?
| It also means that no special
| expiration conditions are required when the phase 1 SAs expire by
| traffic or other usage dependent expirations only, as the old SA
| will eventually expire on its own due to usage.
We don't think that there is a negotiated way to expire Phase 1 SAs by
traffic, is there? (Vague inference from some list traffic.) If not,
this argument doesn't apply.
| 3.4.4 Re-keying Timing
| An example of this is that the end with the higher IP address re-
| keys at 95% of the lifetime, while the end with lower IP address re-
| keys at 85% of the lifetime.
Although this is only an example, this document is quite influential.
We think that there is a better way of breaking the symmetry, and we'd
like it to be used as the example, or even become a recommendation.
We suggest that the bias be towards rekeying by the Initiator over the
Responder. These roles are already an asymmetry in the standards.
The Initiator has already been able to initiate, so the chances of
rekeying succeeding are probably higher if the Initiator re-initiates.
We have actually observed this to make a significant difference.
| Whatever rule is chosen, it is recommended that the rule be
| deterministic in order to have predictable and consistent behaviour
| between peers. If the rule had used the SPI as the determining
| factor (as an example did in the first version of this document),
| different peers would be doing the re-keying at different times.
We have found great value in adding jitter to the rekeying threshold.
True, this adds non-determinacy, but it also helps prevent and cure
"convoy" behaviour. This convoy behaviour was a serious problem with
a hub server.
| 4. Next IPsec Version Recommendations
We would add a few recommendations:
- Make Identity PFS an announced (or negotiated) property so that both
peers know that it is in effect.
- Clarify the meaning of INITIAL-CONTACT. Perhaps make it an ISAKMP
Notification. Perhaps add FINAL-CONTACT.
- authenticate optional payloads in all exchanges. Authenticate the
header (for example, the Commit Bit).
- allow the responder to an Acknowledged Informational to include
information about whether the message was understood or acted upon.
For example, a response to a Delete ought to be able to indicate
whether the deletion was understood. At least some of these
responses should be standardized.
| 4.1 Re-transmission Rules
|
| In systems that use exchanges that have an even number of packets,
| the rules for re-transmission are relatively obvious. Simply put, a
| packet is re-sent if the expected response to it is not received
| within a certain period of time.
|
| However, IPsec has a number of modes that have an odd number of
| packets. This can lead to confusion as to when the re-transmission
| rules should be applied, depending how the re-transmission rules are
| applied to the packets in the exchange. This in turn can lead to the
| dropping of aggressive mode's and quick mode's third messages. It is
| recommended that each of these modes have specific rules applied to
| them to avoid re-transmission issues.
This section distinguishes exchanges that use an even number of
packets (messages) and those that use an odd number. We think that
this is not the best distinction. We will propose another approach.
There are two interesting properties of a message in an exchange:
whether it has a preceding message, and whether it has a following
message. Because peers alternate turns in an exchange, the preceding
and following messages come from the other peer.
If a message has no predecessor, the simple observation is that the
system that sends the message must have decided to do so on its own.
Not much more is worth saying.
If a message has a successor, this successor (if the protocol is
appropriately designed, as IKE seems to be) will serve as an
acknowledgement of receipt. If there is no acknowledgement in a
timely fashion, the message should be retransmitted. Local policy
should determine the rate of retransmission and how persistent it
should be.
If a message has a predecessor, and after the message is sent, a
predecessor is received, it could be ignored. After all, UDP can
re-deliver a message. It might be worth checking to see that the new
message is identical to the earlier one -- but if it is different,
what action should be taken? In any case, this message could be taken
as a sign that the peer hadn't received our most recent message.
Should this trigger a retransmission?
It could be that our last transmission "crossed paths" with the second
copy of the preceding message. Our retransmission could then lead the
other side to retransmit its next message (at least this isn't a
loop). It might be better to just wait to see if we get the
succeeding message in time, and if not *then* retransmit.
This last approach does not work for the last message in an exchange,
because we are not waiting for another message. In that case, the
reception of a preceding message should definitely trigger a
retransmission. This cannot stimulate spurious retransmission from
the peer since this is the last message.
This approach is not as robust as one would like in determining that
the last message needs retransmission. In effect, it depends on a
Negative Acknowledgement. On the other hand, if these Negative
Acknowledgements are not getting through, future communication is
unlikely to work anyway. This may suggest that retransmission should
be more persistent for the second-last message in an exchange.
The only case we haven't covered is that of an exchange with only one
message. This is a case where the last message does not have a
predecessor, so even the NACK isn't available.
We think that this analysis eliminates the needs for sections 4.1.1,
4.1.2, and 4.1.3.
| 4.2 Acknowledged SA Deletion
| The Acknowledged Informational exchange consists of two packets. The
| first packet is the transmission of a notify or delete payload. The
| second is the acknowledgement of that packet.
|
| When used with a delete payload, it is interpreted to mean the
| following:
|
| "I am not sending anymore traffic on this SA (or these SAs). Would
| you please stop sending traffic on it (or them), and send me an
| acknowledgement when you are done?"
This discussion seems to reflect a fundamental misunderstanding of what
Delete does. According to IKEbis, the semantics of Acknowledged SA
Deletion and normal SA Deletion are identical. According to RFC 2408, a
Delete is not a *request*, it is an *announcement*. Specifically, it
announces that a particular *incoming* (at the sender) SA is no longer
usable. It is not a warning of intent to do so, nor a query as to whether
this would be acceptable. It does not say anything about what sorts of
traffic the sender is sending or will send; it says nothing about the
*outgoing* SAs that such traffic would be flowing on. It does not require
any specific action on the part of the recipient.
If the intent here is that associations should be made between
incoming and outgoing IPSEC SAs, so that a Delete would *also* imply a
request to delete any associated SAs in the opposite direction, this
needs to be said much more explicitly.
Consideration also needs to be given to whether a new payload should be
defined to convey this new meaning, and to whether prior negotiation would
be preferable to after-the-fact notification. The draft's discussion
seems to want Acknowledged Delete to be a prior negotiation -- the two
ends are agreeing to stop using certain SAs, with the implication that
those SAs might then be deleted -- but that is *not* what Delete does, and
hence is not what Acknowledged Delete does. Such a drastic change in
semantics would be better accommodated in a new payload, rather than a
redefinition of an old one.
| The receiver of the delete request then switches his outbound
| traffic to another SA, deletes both inbound and outbound SAs and
| sends the delete acknowledgement.
That is a worthwhile convention. And this is a good place to suggest
it. But it isn't in the RFCs, at least not for IPSEC SAs.
It would be nice to have a new Delete that would delete all the SAs in
a suite at once (both directions, ESP, AH, and IPcomp, if present).
It could be part of IPSEC DOI since this particular issue only arises
with IPSEC SA deletion.
Unfortunately, as far as we can tell, the response to an Acknowledged
Informational message in no way indicates whether the responder
understood or acted upon the message.
How should one delete the ISAKMP SA used to carry the deletion
message? This would be useful when shutting down a connection.
| 4.5 Commit Bit Replacement
The Commit Bit has serious problems. Does it fulfill a real need?
The race condition outlined in 2.1.3 is eliminated if the Responder
sets up the inbound SA earlier (we explained why we don't think that
this is a security hole).
If it does fulfill a need, its worst problems can be fixed by
authenticating it (as proposed elsewhere). True, that is a change,
but so are the additions proposed in this section. The proposed
additions seem much more complicated.
Hugh Redelmeier
hugh@mimosa.com
Henry Spencer
henry@spsystems.net