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

[Tero Kivinen <[e-mail]>]

Dan Harkins writes:
> A ticket has to be unforgeable to prevent someone from creating his own
> tickets that would be accepted by a particular responder. If the scheme
> allows forgeries then anybody can create SAs without actually going through
> authentication. I don't think we want to allow that.

Even when they can forge the ticket does not help them at all as they
do not know the keying material associated with the ticket, thus they
cannot create the encrypted and integrity protected parts of the
packet that is required to create SAs. 

> >                            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.

> 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. 

> 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. 

> 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...

> 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. 

> 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.
-- 
[e-mail]
_______________________________________________
IPsec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ipsec