Re: [IPsec] WG Review: IP Security Maintenance and Extensions (ipsecme)

On Tue, July 29, 2008 1:31 am, Tero Kivinen wrote:
> Dan Harkins writes:
>> >                            The real protection is that only valid
>> party
>> > can create the cryptographacally protected part of the message.
>>
>> That's not much protection. A protocol is flawed if an attacker can
>> cause
>> two legitimate parties to think the protocol finished successfully while
>> generating different state. It violates the "Consistency Requirement"
>> (see
>> Hugo Krawczyk's paper SIGMA for a very good description).
>
> Attacker cannot cause either party to think the protocol is finished
> at all. Only the original parties can do that as they are the only
> ones who knows the keys.
>
> Note, that in this case both peers ALREADY have shared secret that is
> used to calculate the integrity of the packet. Ticket is just used to
> tell the responder who is the initiator, so he can use correct shared
> secret key to authenticat the packet initiator sent.
>
> I think you should really read the protocol document first, as I think
> you are missing something big here.

That integrity-protected packet containing the ticket is what gets sent by
the attacker. That packet is not cryptographically bound to anything else.
While an attacker cannot create the packet, it can send that packet from
any IP address just as easily as a legitimate client can. This causes the
problem I discussed.

>> An attacker could manipulate IP addresses during this exchange and the
>> result would be that the initiator thinks the SA is between IDi and IDr
>> at IP address X and IP address Y, respectively. The responder thinks the
>> SA is between IDi and IDr at IP address Z and IP address Y,
>> respectively.
>
> And if X and Z are different then responder will ignore the Z as it
> does not match the stored data in the database. Or if mobike is used
> then the mobike payloads inside the encrypted parts will tell
> both ends that there is NAT between them and they will work around it.

Except it doesn't say in the spec to match the address of the sender
against some external source.

So the security of the protocol relies on unstated checks. Is that the
only one or are there others? What is your aversion to using cryptography
to solve this problem?

>> That is an undetectable failure by both the initiator and responder
>> therefore that protocol is flawed.
>
> Responder will detect this by comparing the outer addresses to the
> database if no MOBIKE is used. If MOBIKE is used then both ends will
> detect that NAT_DETECTION_*_IP notifies do not match, and there is NAT
> between the peers, and will cope with that NAT (or in this case
> attacker).
>
>> The attacker could also just record
>> the legitimate exchange and then play it back in its entirety from
>> different IP addresses. Yes, the attacker doesn't know the key but the
>> responder thinks it has an SA with someone who doesn't exist at the
>> place it thinks that someone exists. The protocol is flawed.
>
> If you read the protocol description it says each ticket is usable
> only once. Thus after the legimate exchange is finished, the ticket is
> destroyed and new one is created, i.e. in this case the ticket in the
> database is marked as used and the responder issues new integer ticket
> number for the initiator, and initiator will use that next time.

I read the protocol. It says, "Tickets are intended for one-time use: a
client MUST NOT reuse a ticket, either with the same or with a different
gateway.  A gateway SHOULD reject a reused ticket."

But attackers typically don't follow MUST and SHOULD rules in an RFC.
And a gateway upon receipt of a packet containing a ticket does not know
whether it's from a client who is faithfully following the rules or from
an attacker who is not.

A gateway can retain all tickets it has processed to make sure they're
not reused but for 100,000+ clients (to use Yoav's example) that gets
to be a burden. Or the protocol suggests making a "cookie request" to deal
with replay attacks. And in the event of a crash and restart 100,000+
resumption packets from 100,000+ clients will look quite a bit like an
attack.

>> This is fixable but it requires specifying behavior in creation of the
>> ticket. Or it requires unfounded assumptions to be made about the
>> security
>> knowledge of implementors-- remember, if it's just an opaque blob then
>> the creation and processing of it is entirely up to the imagination of
>> the implementor.
>
> Yes. And we are here to specify protocols, not writing
> implementations. Implementor can mess up things way easier, than doing
> bad ticket generation, buffer overflows and such are much easier
> mistakes to make...

So then let's not make it easier to mess up! What's wrong with a robust
protocol?

>> But if the protocol had cryptographic checks built in such that the
>> man-in-the-middle, or replay, attack above would result in a
>> verification
>> failure of the ticket then proper implementation of the specification
>> would
>> result in some level of security. We could actually describe some
>> security
>> features of the protocol.
>
> As nobody else than the implementor can have any way to verify that
> those rules are followed (nobody else do not have the key required to
> decrypt the blob), then mandating such things does not help, as if
> implementor still wants to mess up things he can do so. Also rules
> you put out forbids one of those very useful implementation
> architecture. If the gateway has persisntent storage, it can store the
> material there, and there is no need to use opaque encrypted blobs,
> just the a handle to that persistent data.

You said twice in your post that I should read the protocol. But you know
what? Maybe you should read the protocol. I'm not forbidding your "very
useful implementation architecture." Section 5.1 is doing that.

>> It could. But then, again, it could not. And even if it was, so what?
>> That doesn't make it secure. If construction of the ticket is
>> out-of-scope
>> then you can't say what the ticket might or might not be. It can be
>> everything and anything, secure or insecure. All would be equally
>> acceptable. And that seems so very wrong to me.
>
> Then we disagree here, and I do not think we should continue this. I
> think it would be fine to provide example of good ticket generation
> guidelines (like we do for example for cookies in the IKEv2), but
> mandating anything for that kind of blob should be out of the scope.

Yes, we do disagree. I want a protocol which uses cryptographic tools to
solve some obvious problems; you want to solve them by unstated and
non-cryptographic verification of external data. I want a protocol that,
when implemented correctly, can claim some well-founded security features;
you want a protocol that cannot claim any real security features.

If you think the spec should not mandate any particular construction or
behavior then fine, state that. We can disagree about what the spec should
say. But why make this topic out-of-scope? Why is robust security something
to be avoided ("if implementor still wants to mess up things he can do
so")?

I looked through the recent postings on this list and can't find anything
that discusses ticket creation as being out-of-scope. It just appeared in
the charter. Can someone please point me to the postings on the list that
discuss the rationale behind this? Where did this statement about
out-of-scope come from?

  Dan.

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec