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

[Tero Kivinen <[e-mail]>]

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. The real protection is that only valid party
can create the cryptographacally protected part of the message. 

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

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

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