Re: Request for Comments: Nping Echo Protocol

[Brandon Enright <bmenrigh () ucsd edu>]

Hi Luis.  Sorry for the delayed response.  We've been so pwned in the
last week that even finding time on the weekend for a response has been
difficult.

Before I start giving any crypto advice, keep in mind that:

* I am not a cryptographer
* I don't play a cryptographer on TV
* I don't know jack about cryptography
* I didn't stay at a Holiday Inn last night


On Wed, 22 Jul 2009 14:18:28 +0200 or thereabouts "Luis M."
<luis.mgarc () gmail com> wrote:

>     2.11 Security
>
>         The Nping Echo functionality involves direct access to
> network traffic on the server side and that can easily involve
> information leakage problems if no security measures are taken.

Ack.
 
>         Unless Nping is compiled without OpenSSL support,

You haven't described what happens if you use a client compiled with
OpenSSL but a server without or vice versa.  I'd suggest that the
server and client both require a flag like "--unencrypted" to allow
fallback no encryption.  A server/client compiled without OpenSSL
should return a fatal warning if used without --unencrypted.  This will
prevent a MitM attack degrading the channel to no encryption.

> all Nping
> Echo Protocol (NEP) packets are transmitted encrypted. Rijndael/AES
> standard is used. It has a block size of 128 bits, that's why all NEP
> packets must have a lenght that is multiple of 16 bytes.

Whoa, lets not throw names like AES around without talking about the
mode too.  ECB would be disastrous.  At the minimum CBC should be
used, I'd suggest using CTR mode though because it will fit in nicely
with the nonce (described below).

>         Every NEP packet includes a SHA-256 checksum. SHA-256 has
> been chosen over MD5 or SHA1, just to be safe in the future. MD5 is
> already broken and some studies show important advances in SHA1
> attacks.

Okay, SHA-256.  It's overkill but you're right that there isn't a good
smaller alternative.  We could truncate SHA-256 to only 128 bits but
since we aren't pressed for space, might as well use the full 256.

As for using the hash as a checksum, actually I think you want to use
the hash as a MAC (message authentication code).  The difference is
subtle.  In one case you are trying to detect errors, in the other
case, you are looking to thwart attackers.

>         As described above, client authentication is performed using
> the checksum field. The server assumes only a client in possesion of
> the correct encryption key is capable of producing packets that, when
>         decrypted, contain valid SHA-256 checksum.

This is not a safe assumption.  Encryption is good at hiding contents,
it is bad at resisting certain types of attacks.

Matasano *just* did a long and annoying blog post about this very thing:

http://74.125.155.132/search?q=cache:693pTMNFilMJ:www.matasano.com/log/1749/typing-the-letters-a-e-s-into-your-code-youre-doing-it-wrong/+matsano+aes&cd=1&hl=en&ct=clnk&gl=us

(Their blog was just hacked so the above is from Google's cache.
Ironic, I know)

In short, you want to use the encryption to protect the contents.  You
want to use a MAC to authenticate the contents.

Put another way, the SHA-3 competition would not exist if one could
just use AES.

> However, replay
> attacks may be possible in this scheme. A small 32bit Sequence field
> is included in every packet.

Yes but 32 bits is way to small.  You're using SHA-256, your nonce
should be 256 bits too.  This will come into play with the mode you run
AES in.  More on that later.

> In theory, the server could have a list
>         of sequence numbers that have already been used and deny
> connection to clients that use replayed packets. However, a 32 bit
> space may not be sufficiently large to provide security, and
> exhaustion of sequence numbers may result in a denial of service for
> authorized clients. 

Better to make the server inform the client what the starting nonce is.

<I've cut the rest of your proposal because I don't think it directly
applies if we use a 256 bit nonce and a MAC with AES-CTR>

So how would this all fit together?

For a nonce (sequence number/IV), something randomly generated by the
server should do.  It will be transmitted in plain-text which is okay.

For a MAC, we should use HMAC-SHA-256.

For a PSK, we should use iterated SHA-256.  I'd suggest 128k
iterations.  That is, if somebody shares the key "pass" then "pass"
should be hashed with SHA-256 128k times.  If that seems to take too
long maybe only 64k or even 4k iterations is enough.  You want the
whole iteration process to take about 100ms on an average computer.
The calculation only needs to happen once on the server side and once
on the client side.

The derived PSK can be used as the key to both AES256-CTR and
HMAC-SHA-256.


The client can prove that it has the PSK by computing the HMAC(nonce,
PSK).

That would look something like:

server -> client:
"hello" + <nonce>
client -> server:
hmac("reply" + <nonce>, <psk>)

You can fit this exchange in with the rest of the protocol exchange.
It allows the client to prove that it is legit to the server.  If you
want the server to prove that it is legit to the client do something
like:

server -> client:
<servernonce>, hmac("hello" + <servernonce>, <psk>), <clientnonce>
client -> server:
hmac("reply" + <clientnonce>, <psk>)


Once the client and server have authorized each other and established a
nonce for each, then the messages can be encrypted like so:

ciphertext = <nonce> + AES-256-CTR(<message>, <nonce>)
ciphertext = <ciphertext> + hmac(<ciphertext>, <psk>)

The server should use the server nonce and the client should use the
client nonce.


This email has gone on long enough and I'm sure it's pretty confusing.
If you have any questions or quibbles let me know.  If you are having
trouble understanding my pseudo-protocol let me know and I can code a
working version in perl.

If you want to know why I've setup the PSK in the way that I have or
why we should use hmac or CTR mode, let me know and I'll try to
elaborate.  If you see any obvious mistakes or omissions I'd like to
know about those too :-p

Brandon


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org