nping echo protocol rfc, feedback

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

  Hey,

I read the nping echo protocol rfc. It is well written. Some details
were a bit unclear to me. Below I try to complain as much as possible.
I am hoping my comments will help to polish the writing.

In chapter 2.2 the description of Message Type says "It must be one of
the type codes defined in section 2.2."
I think the section number here is wrong.

There are some fields in the spec that store timestamps, and after
reading the whole spec it remains unclear to me which time zone the
time stamps should be in.

For some reason the timestamp field is explained for each message type
separately. The description seems to be always the same. Some other
shared fields are only explained once, in the chapter about the
general message format.

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.

The PAYLOAD_MAGIC picture shows a Length field, but the length of the
Length field is not mentioned anywhere. From the picture I'd assume
that it is one byte, but I would want to read it from somewhere to be
sure I understand it correctly.

In chapter 2.8 the description of Packet Length field ends "...must
not exceed 9212 bytes." I think this should be changed to be more
explicit whether it is discussing the data or the field. Either "The
echoed packet must not exceed 9219 bytes." or "The value stored in
this field should never be bigger than 9212."

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.

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.

The explanation about receiving encrypted messages states about the
first step: "Reads 128 bits and decrypts them." What exactly does
decrypting here mean? Some messages are encrypted partially and some
are not encrypted at all. Should they still be decrypted somehow?

step six has a minor language error "higher or equal than" -> "higher
than or equal to"

step seven. I stared at the equation for some time before
understanding what it means. Maybe it could be moved to context in the
sentence or clarified with (remaining = TotelLength - 128bits)

In the following paragraph I would replace "this last statement" with
the statement itself. The paragraph also states that "all messages are
encrypted" I think the beginning of the spec stated really explicitly
that the first message is not encrypted.

In 2.13 there is a typo "sesson" -> "session"

a bit forward "As described above, a total of 5 symmetric keys are
used." I would change "described" to "mentioned" as the earlier
description was not too long.

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.

Some things seem to be missing from the rfc. It seems that the
encryption key needs to be truncated before it is used as a key for
the hmac authentication codes. Openssl did not complain to me when I
tried to use a longer key. I am not sure, if it would have worked
correctly. Also, how does the encryptionless mode work? Is it out of
the scope of this specification? What kind of security risks does this
service impose on ones system?

I am also not sure I understood how the encryption IVs and nonces
should be carried in a long discussion from message to message. I
might very well be lacking in my theoretical background. I get the
feeling that this is based on some more general patterns that I am not
too familiar with. Maybe it can be clarified, but maybe that is not
necessary.

Finally, examples for encryption and hmac would help in debugging
implementations. Having even one example of the password, nonce and
typeid, and the key they are supposed to produce would make initial
debugging a breeze. Not to mention similar examples of the encryption
and mac. I realize such examples might be too long to be included
within the text. Maybe they could be included in some sort of
appendix?

An interesting protocol it is. Keep up the good work. --Toni
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/