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

["Dan Harkins" <[e-mail]>]

  Hi Tero,

On Mon, July 28, 2008 5:07 pm, Tero Kivinen wrote:
> Dan Harkins writes:
>>   Your example was to send the 64-bit index into a database as the
>> ticket.
>> I'm sure that's not what you propose to do and was just an example but
>> it illustrates why we need some base requirements around construction of
>> the ticket. Such a ticket is forgeable and nothing binds a peer to such
>> a ticket. The scheme would probably rely on layers of checks ("is the
>> claimed sender of this ticket the same as the address in the SA pointed
>> to by this ticket index?", etc) to ensure the ticket isn't misused
>> instead
>> of having a robust cryptographic check to ensure proper ticket usage.
>
> Running index would be perfectly good ticket and would be perfectly
> secure. The initiator doing the resumption will give that ticket to
> the responder, responder will look up the keys and other material from
> the database, and then decrypt the rest of the encrypted message and
> verify the integrity of it. After that it will mark the index in the
> database as "used" so it cannot be used anymore. The initiator has
> proven the knowledge of the key associated to the ticket (but not
> wrapped in to the ticket, as it was in the database instead) by being
> able to create the encrypted and integrity protected parts of the
> message. Any other peer would be knowing the keys to generate
> cryptographically integrity portected message so that should prevent
> anybody else using the ticket (unless the original party of the
> initial IKE SA creation gives out the keys).
>
> I do not understand why the ticket must be unforgeable or why it must
> be indistinguishable from random? Those requirements do not make any
> sense for me in this kind of database case. Anybody can see the ticket
> immediately when it is first time used and attacker just needs to read
> the ticket from there and block those packets from reaching the
> recipient and then he can use the ticket if that would be the only
> protection on the ticket.

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.

Indistinguishable from random, for some number of adversary queries, is a
yardstick by which to measure security. Any cryptographic system is
breakable, in principle, after enough time and effort. So "security"
becomes a function of the amount of time and effort an attacker must use
to break the system. If it can be shown that an attacker cannot gain an
advantage in breaking the system after X queries, and X is sufficiently
large (like 2^80 or 2^128), then one can quantify "security" to a certain
degree. That seems like a worthwhile thing to do.

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

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.
That is an undetectable failure by both the initiator and responder
therefore that protocol is flawed. 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.

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.

>>   Another bad example of ticket creation would be to create a keystream
>> with a hash function, seeded with some password, and XOR the keystream
>> with each ticket to create the opaque blob. A naive implementor who is
>> not security savvy might come up with such a scheme. We should prevent
>> someone from claiming compliance with a standards track RFC from the
>> Security Area of the IETF if they have such a lame scheme.
>
> Yes, that would be very bad ticket.

Yet if the ticket is just an unspecified opaque blob this is entirely
possible. It's possible for someone to correctly implement the protocol
and end up with an something that is flawed from a security perspective.

Security protocols should be robust.

> The vendor could also post those tickets and their decrypted content
> to the wikipedia for storage, and that would also be bad way to do
> tickets, but I still do not think we need to add rules forbidding
> that...

That's a ridiculous argument. Publishing secret data anywhere serves no
purpose. The point being made is that someone can correctly implement the
protocol but since the security of it depends on critical decisions they
make the end result may not be secure. Therefore the protocol is not
secure, certain implementations may or may not be secure but the protocol
is not.

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.

>>   This is a security protocol and we should make sure it's secure. To do
>> so we should specify _minimum_ behavior to comply with reasonable
>> security
>> requirements. A base blob communication protocol whose entire security
>> is left up to the imagination of the implementor is not what a standards
>> track RFC out of the Security Area of the IETF should be, in my opinion
>> anyway.
>
> But as has been pointed out the ticket might not be just opaque blob
> communication, it could also be representated as handle to some
> internal persistent data structure.

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.

  regards,

  Dan.



_______________________________________________
IPsec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ipsec