Re: nping echo protocol rfc, feedback

[Toni Ruottu <toni.ruottu () iki fi>]

> > 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
> > connection.
>
> 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
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/