mailing list archives
Re: nping echo protocol rfc, feedback
From: Toni Ruottu <toni.ruottu () iki fi>
Date: Fri, 11 Mar 2011 16:59:40 +0200
In chapter 2.6 the description of Client Nonce field states "Nonce
value received from the client in the previous
NEP_HANDSHAKE_CLIENT message." I understood previously that there
could be only one NEP_HANDSHAKE_CLIENT message sent over one
connection. At this point I started wondering, if the server should
use the previous one even when that was received over another
Mmm, I'm not sure I'm following you. The initial handshake is a
three-way handshake defined as:
1) S -> C NEP_HANDSHAKE_SERVER
2) C -> S NEP_HANDSHAKE_CLIENT
3) S -> C NEP_HANDSHAKE_FINAL
In the last message, what the server does is echoing the nonce received
from the client in step 2. If the server does not receive a
NEP_HANDSHAKE_CLIENT, it would not produce any NEP_HANDSHAKE_FINAL, so
there is always a client-generated nonce to echo in the
NEP_HANDSHAKE_FINAL message. Also, the server does not keep state after
a NEP session has ended, so two subsequent connections from the same
client are treated as separate connections from different clients.
There could be multiple simultaneous connections in which case the
"the previous NEP_HANDSHAKE_CLIENT message" might have arrived over
another connection. Changing this to "the preceding
NEP_HANDSHAKE_CLIENT message" would clarify the situation, if I
understood the meaning correctly.
Chapter 2.10 has an example at the of the first paragraph. It starts
with "eg:" and lists examples, then it ends with "etc". One or the
other should be dropped. The list is not expected to be complete
because it is just a list of example, so etc is not needed.
Alternatively one could drop "eg:" making it a complete list, and
stating "etc" at the end to cut the list. With "etc" the way the list
continues should probably be obvious from the example provided, so
maybe dropping "etc" and keeping "eg" makes more sense. I think eg is
written "e.g." as it is an acronym for two words, but I am not exactly
sure about this.
You are right. These kind of things are hard to notice for me, as I'm
not a native english speaker. I know you are not either, but you guys in
northern Europe are always ahead of us, poor southern Europeans ;)
It is just easier to notice these things when someone else did the writing.
In the same chapter the explanation of Error Message field explains
requirements for null characters. I think it would make sense to
clarify that the last byte of the field needs to be null in all cases.
I don't agree with this one. I thinks that can be trivially inferred
from the description.
It can be inferred, but it is also a fact that always holds. And
stating facts that always hold is useful. Any other part of the
explanation only affects the end result, while having the last byte
always be null, is a safety measure. Of course an implementation
should not rely on the last byte being null.
I am worried that someone might store an error message which is
exactly 640bits, thinking that the terminator is not required when the
whole field is used. Alternatively you could clarify the maximum
length of the message. "The null terminator always takes one byte,
leaving 632bits for the string payload."
In the key explanations sometimes the concatenation is marked as
(SERVER_NONCE|CLIENT_NONCE) and sometimes not. I tried really hard to
figure out if the two cases were different, but I am still not sure. I
think they are the same. Maybe the notation should be copied to all
cases or dropped.
You are right. I've replaced the "|" symbol with the plus sign to make
all concatenations consistent.
That was not the problem. I'll clarify
For NEP_KEY_MAC_C2S it is said that "NONCES equals the server nonce in
the NEP_HANDSHAKE_SERVER message, concatenated with the client nonce
in the NEP_HANDSHAKE_CLIENT message (SERVER_NONCE + CLIENT_NONCE)"
For NEP_KEY_CIPHERTEXT_C2S it is said that "NONCES equals the server
nonce in the NEP_HANDSHAKE_SERVER message, concatenated with the
client nonce in the NEP_HANDSHAKE_CLIENT message."
Why is the later one lacking the equation? Some of the descriptions
have the equation and some do not have it. Is there a difference?
Should all of them have the equation?
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/