[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: problems with draft-jenkins-ipsec-rekeying-06.txt
All,
Let me preface this response with a few comments.
First, my understanding of an information RFC "... does not represent an
Internet community consensus or recommendation" and that it is intended to
provide a mechanism to allow the presentation of information related to IETF
activities. (Quotes are from section 4.2.2 of RFC 2026 "Internet Standards
Process".)
Given that I believe and have been told by others that the information in
this document is of value to IPsec implementors, I wanted to make the
information available persistently. The only way that I know how to do that
under the current circumstances is to make it an informational RFC.
I believe the document provides ideas and thoughts for implementors dealing
with the current standards-track RFCs, and provides potential ideas for
future discussion on the standards-track RFCs.
Additionally, I have neither the mandate nor the bandwidth to spend a lot of
time on this document anymore. So, if it is not appropriate as an
informational RFC with only relatively minor changes, then I will be forced
to abandon it. What this means is that I need a definitive answer as to the
suitability of the document as an informational RFC. (I understand I have to
remove references to IKEbis in any case.)
Now, I'll attempt to respond to the specifics.
> -----Original Message-----
> From: D. Hugh Redelmeier [mailto:hugh@mimosa.com]
> Sent: Wednesday, July 12, 2000 6:10 PM
> To: IPsec List
> Cc: Hugh Daniel; John Gilmore
> Subject: 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.
I think later you recognize this is due to potential replay, and you solve
this by recording previously used message IDs within the phase 1 SA from
that peer. Your justification is that message IDs are required by the RFCs
to be unique.
I am unable to find such a requirement. RFC 2408 section 3.1 only says "This
value is randomly generated by the initiator of the Phase 2 negotiation." In
practise, this may mean that it is unique, but it's not a requirement.
So, my conclusion is that based on the RFCs as they stand, there is a
potential hole.
>
> | 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).
See above about the uniqueness requirement.
>
>
> | 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.
I don't understand what you're objecting to here. Yes, it's obvious that
leaving an old SA up longer (when permitted) aids interoperability, but how
long provides real value? The 30 second suggestion is based on
implementation experience, as stated in the first paragraph of that section.
>
>
> | 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.)
Your comments on INITIAL-CONTACT are applicable to the RFCs and not to this
document.
Further, I disagree that the use of INITIAL-CONTACT is not allowed in main
mode by the RFCs. If the INITIAL-CONTACT is passed in one of the encrypted
main mode exchanges, and not acted upon until main mode is complete, what is
the problem?
>
> | 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.
Which document? Again, I think your comments apply to the RFCs, not this
document.
>
> | 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*.
See above; I disagree with this.
>
>
> | 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.
I think the intent of the section is clear: what do you do when there is
more than phase 1 SA that can be used? Do I really need to define peer more
explicitly here?
This section is not about how to decide if you have two phase 1 SAs with the
same peer. It might be a worthwhile discussion, but it's out of scope of
this document.
(If asked to define what multiple ISAKMP SAs with same peer means, I would
say that the the phase 1 IDs matching is the requirement.)
>
> | 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.
Again, this document is intended to be information only, to attempt to help
make implementors aware of issues and options.
Does the existence of alternatives make this document invalid as
informational?
>
> | 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.
Are you saying that since the waste is little there's no value in stating
this as a reason?
>
> | 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.
Well, IKEbis might deprecate phase 1 SA lifetime negotiation by traffic, but
it's still in the RFCs as being usable.
There was also talk of adding a "number of keys generated" parameter that
could be negotiated for phase 1. That would be similar to a traffic value.
>
>
> | 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.
I'll look into substituting your suggestion as the example.
>
> | 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.
I can add some comments about jitter as well.
>
>
> | 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.
>
All of these suggestions are beyond the scope of this document, and they're
also not mine. This document is not intended to be IKEbis. I would recommend
you pursue them separately, since they are things that should be in IKEbis.
>
> | 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.
Again, this document is informational, and makes suggestions. Its contents
could be used as a basis for future discussions of the standards. The
publication of this document does nothing to prevent the standards from
adopting your proposal.
My points here are:
1) I don't wish to debate which method is better. I expect both will work.
2) I don't believe that the existence of another proposal should keep this
document from being made informational, as I understand the intent of
informational.
>
>
> | 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.
>From an operational point of view, meaning, intending to drop as few of the
user's packets as possible, yes this is the intent.
RFC 2408's meaning is not lost. My suggestions can still be considered an
announcement, they just provide an opportunity for the peer to react so that
it reduces the probability of lost packets.
>
> 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.
I feel you are over-stating the differences. Perhaps it's not clear in the
draft that if no response is received to the delete notification, the SAs
will be deleted anyway.
Again, the only difference is instead of saying "This is an announcement
that my inbound SA is deleted", it's saying "This is an announcement that my
inbound SA is going to be deleted soon; please tell me that you heard me say
this".
The wording I used in the draft was intended to convey some operational
stuff at the same time.
>
>
> | 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.
>
These comments are valid for discussion about IKEbis, but I don't understand
what you're looking for with respect to the rekeying document.
>
> How should one delete the ISAKMP SA used to carry the deletion
> message? This would be useful when shutting down a connection.
This is a valid question, but the fact that this document doesn't answer
that shouldn't stop its acceptable as informational, right? That question
should be answered in ISAKMPbis/IKEbis/whatever.
>
>
> | 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.
Again, they are proposals only, in what intended as informational. They are
intended to provide ideas moving forward.
Also again, I don't believe the race condition is eliminated.
>
> Hugh Redelmeier
> hugh@mimosa.com
>
> Henry Spencer
> henry@spsystems.net
>
Tim
Follow-Ups: