[p2p-hackers] amicima's MFP - preannouncement

[Matthew Kaufman]

Alex Pankratov:
> 
> Matthew,
> 
> I can't seem to find the mentioning of replay protection in 
> your protocol. Also encrypted packets don't seem to carry any 
> sort of HMAC, which is also a bit odd. Perhaps these details 
> are just missing from the spec, in which case it might make 
> sense to produce a separate security-oriented description of 
> the protocol.
> 
> Alex

The packet-level protocol spec is admittedly short on information about how
exactly to use the protocol (and a followup document is being edited and
will be up soon). However if you examine the brief description of the
startup sequence, you get some hints as to how this works.

The goal is to get an encrypted session up in as few round trip times as
possible, so the session keying is overlapped with the session handshaking.
Then flows can come up simply by sending data on them, so subsequent flows
on an established session come up in even fewer round trip times. The
Simplified Digital Certificate format is also compact, so that fragmentation
can likely be avoided.

So specifically, if you assume RSA and AES (or something else that lets you
have public-key crypto and fast symmetric crypto, noting that the choice of
cryptosystem is not mandated by the protocol, and in fact you could run with
no cryptography and simply get replay resistance that is "as good as TCP"
(but a protocol that would still be more resistant to "SYN flood"
attacks))...

A Responder Hello chunk could be forged, by replying with the correct tag
data echo, an arbitrary cookie, and a copy of someone else's certificate.
However, when the other end sends its Initiator Initial Keying, the session
key to be used is encypted with the public key in that certificate, so
unless you also have the matching private key, forging a Responder Hello
doesn't help you except to possibly cause denial of service. Our
implementation supports parallel-open, so if *any* of the endpoints being
opened to is actually the right one, you'll still get a session up (better
than TCP's situation in that case). And clearly we can't protect against the
case where all packets to the valid destination are intercepted and
discarded.

The Initiator Initial Keying chunk is also signed using the private key
associated with the Initator's certificate which is included, and that
signature covers the Cookie Echo field... That protects against replay in
one direction, in that the Responder got to choose the (new, unique) cookie
data, and is forcing the Initiator to prove that they have the private key
(and aren't simply replaying) by signing that unique data.

At the same time, the Initiator gets to choose the (new, unique) Session
Key, and by extension is choosing the Encrypted Session Key. The Responder
is then forced to prove that they have their private key (and aren't simply
replaying) by successfully decrypting that session key using their private
key. If the Responder fails to do that, then it can't send a Responder
Keying Ack encrypted with the proper key.

Replay of session data after the session is up then only works if the
session that is being replayed has a Session ID and a Session Key which
match a session which is up, otherwise the data is discarded at the receiver
as being unrecognized. We make the assumption that this is very unlikely
except in the case where data is simply being replayed after a relatively
short delay by a third party. This replay is also limited to entire intact
packets, because the encryption prevents the contents from being modified or
added to without damaging the packet such that it will be ignored at the
receiver, unless the attacker was able to get the session key by a brute
force attack on AES, or by monitoring the session startup and having the
private RSA key of an endpoint.

If the third party doing the replaying forges the source IP address to match
the real sender, then it simply looks like duplicated packets, and the
sequence numbering used on all the flows and acknowledgements is already
prepared to deal just fine with duplicated or reordered packets, even for
unreliable or unordered-reception flows, so there's no effect on the
application.

If the third party doing the replaying uses a new source IP address, then it
looks to our implementation like IP mobility is occuring... that is, an
endpoint has changed its IP address.

However, in our IP mobility support, the return data flow is not moved to
the "new" IP address until a unique and timestamped message sent to the
"new" IP address can be echoed back (with modification) from that "new"
address... Thus, unless the attacker can actually decrypt the session
traffic, they will be unable to provide the correct return data, and so the
packets from the "new" address will simply be ignored as above, except for
the rate-limited probes to see if actual mobility has occurred.

As for a per-packet HMAC, this is most valuable for non-encrypted data. An
HMAC is a hash generated from the combination of the packet data and a
shared secret... We essentially have this, in that a session key (a shared
secret) is used to encrypt the packet and its checksum. If one wished to use
the MFP protocol unencrypted, a valuable extension might be to provide for a
separate HMAC, but we expect most users to run with encryption, since these
days everything really should be encrypted, and with MFP there is no
round-trip-time penalty to using it, nor any restriction on passing
unreliable or unordered data like you'd have with SSL over TCP.

Matthew Kaufman
matthew at amicima.com
matthew at matthew.at
www.amicima.com