3
$\begingroup$

Consider such authentication protocol:

Alice and Bob share a key.

  1. Bob sends alice a nonce.

  2. Alice encrypts it with shared key and sends to bob.

Now assume Alice was successfully authenticated.

But there is such attack mentioned

Trudy can hijack connection after authentication, if she can send packets with Alice’s source address

This seems to be a general problem with authentication protocols. Even if steps 1 and 2 are secure and authentication protocol is secure, trudy can always mount above mentioned attack after the authentication protocol is finished, isn't it? How are such problems dealt with?

Improve this question
$\endgroup$
2
  • 1
    $\begingroup$ by combining authentication with integrity preserving transport mechanisms (i.e. bind the authentication to a specific TLS connection). $\endgroup$
    – SEJPM
    Commented Dec 25, 2015 at 11:56
  • $\begingroup$ @SEJPM Can you elaborate how and why does that prevent above attack ? (maybe as an answer) $\endgroup$
    – user29112
    Commented Dec 25, 2015 at 11:58

2 Answers 2

Reset to default
1
$\begingroup$

This is usually solved by creating a session key as part of the authentication process, then using authenticated encryption for the whole session. This is how e.g. TLS does it. Even if an attacker could hijack the connection, they do not have the session key so they cannot produce valid data.

The session key can be constructed in various ways. For example, a very simple, purely symmetric key protocol could have Alice generate a random key, encrypt the nonce using that key and the session key using the longer term key. The rest of the session would be encrypted and authenticated using the session key.

In practice it is a good idea to use something like Diffie-Hellman key exchange, since it gets you forward secrecy, among other things.

Improve this answer
$\endgroup$
4
  • $\begingroup$ Can you elaborate more how and why this prevents the attack I mentioned? $\endgroup$
    – user29112
    Commented Dec 25, 2015 at 12:38
  • $\begingroup$ @user200312, added a line. It's basically the same reason Alice's encrypted nonce works as authentication in the first place. $\endgroup$
    – otus
    Commented Dec 25, 2015 at 12:41
  • $\begingroup$ Aha so it is about sending something to the server after authentication protocol. Once authentication completes one should send some data to the server, otherwise why need for authentication in first place, right? $\endgroup$
    – user29112
    Commented Dec 25, 2015 at 13:23
  • $\begingroup$ @user200312, yes, there would be no point in authenticating someone if you have no data to exchange. $\endgroup$
    – otus
    Commented Dec 25, 2015 at 16:02
1
$\begingroup$

TL;DR: The mentioned attack only works against plaintext connections.

Alice and Bob share a key.

If this is the case, you shouldn't roll your own protocol. Just rely on the power of TLS and its PSK ciphersuites - preferably the ones which offer forward secrecy by also using an (EC)DHE exchange.
If and only if both parties share the same key, the TLS handshake will suceed and anything identified with either party has to be encrypted and authenticated with that party's session keys. So if Trudy sends some message using Alice's source address (but not with Alice's session keys) the MAC verification will fail and the connection will be aborted as an attack has been registered.

How are such problems dealt with?

If you really deploy a custom authentication protocol, you should always run them over TLS (either server-authenticated or opportunistic). This allows you to associate a given party (Alice) with a given other end of a specific TLS connection. If anything "from that party" comes in that doesn't use the right keys, the MAC verification will fail and the connection will be dropped.

I was curious about nature of the attack I described

The attack works by spoofing the source adress. If there are no counter measures in place and the attacker gets the source (IP) adress of Alice he can send arbitrary requests as Alice if Alice is only recognized by her source adress (and not ownage of keys or even cookies). However the answers to these requests will still be sent to the real Alice (unless tha attacker attacks the authentication protocol in a clever way by acting as a man-in-the-middle) but they can do harm nonetheless.

Improve this answer
$\endgroup$
1
  • 2
    $\begingroup$ Yes but I am trying to understand things, not implement-that is why I was curious about nature of the attack I described, when/how it occurs etc. $\endgroup$
    – user29112
    Commented Dec 25, 2015 at 12:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.