mirror of
https://github.com/nmap/nmap.git
synced 2025-12-14 11:49:01 +00:00
1159 lines
57 KiB
Plaintext
1159 lines
57 KiB
Plaintext
+-----------------------------------------------------------------------------+
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NPING ECHO PROTOCOL
|
|
|
|
|
|
|
|
|
|
PROTOCOL SPECIFICATION
|
|
|
|
Request for Comments
|
|
|
|
August 2010
|
|
|
|
|
|
|
|
|
|
|
|
Luis MartinGarcia
|
|
(luis.mgarc@gmail.com)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
+-----------------------------------------------------------------------------+
|
|
|
|
Status of this document: DRAFT
|
|
First version: May 29, 2009.
|
|
Last revision date: April 27, 2011.
|
|
|
|
+-----------------------------------------------------------------------------+
|
|
|
|
|
|
|
|
PREFACE
|
|
|
|
This documents presents the technical specification of the Nping Echo Protocol.
|
|
|
|
|
|
|
|
|
|
TABLE OF CONTENTS
|
|
|
|
1. INTRODUCTION ..................................................... x
|
|
|
|
2. NPING ECHO PROTOCOL SPECIFICATION................................. x
|
|
|
|
2.1 General Message Format......................................... x
|
|
2.2 Field Description.............................................. x
|
|
2.3 Message type codes............................................. x
|
|
2.4 Message NEP_HANDSHAKE_SERVER................................... x
|
|
2.5 Message NEP_HANDSHAKE_CLIENT................................... x
|
|
2.6 Message NEP_HANDSHAKE_FINAL.................................... x
|
|
2.7 Operation NEP_PACKET_SPEC...................................... x
|
|
2.8 Operation NEP_READY............................................ x
|
|
2.9 Operation NEP_ECHO............................................. x
|
|
2.10 Operation NEP_ERROR............................................ x
|
|
2.11 Flow diagrams.................................................. x
|
|
2.12 Security....................................................... x
|
|
2.13 Cryptographic key derivation................................... x
|
|
2.14 Encryption process............................................. x
|
|
2.15 Additional considerations...................................... x
|
|
|
|
3. GLOSSARY .......................................................... x
|
|
|
|
4. REFERENCES ........................................................ x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1. INTRODUCTION
|
|
|
|
Troubleshooting routing and firewall issues is a common task nowadays.
|
|
The scenario is generally that some network traffic should be flowing
|
|
but isn't. The causes of problem can range from routing issues to
|
|
network firewall to host-based firewalls to all sorts of other strange
|
|
things. It is usually the "middle box" problem that is the hardest to
|
|
find.
|
|
|
|
Suppose there is some host with a TCP service listening that you can't
|
|
connect to for an unknown reason. If a Nmap -sS scan doesn't show the
|
|
port as open there are a multitude of possible problems. Maybe the SYN
|
|
packet never made it because of some firewall in the middle. Maybe the
|
|
SYN did make it but the SYN+ACK got dropped on its way back to you.
|
|
Maybe the TTL expired in transit but the ICMP message got blocked by
|
|
another firewall before making it back to you. Maybe the SYN made it
|
|
but some intermediate host forged a reset packet to snipe the connection
|
|
before the SYN+ACK made it back to you.
|
|
|
|
When things like the above are going on it is often the case that even
|
|
nping can't track down the problem alone. One generally has to turn to
|
|
Wireshark/tcpdump on one station and nping on the other but sometimes
|
|
it may be quite difficult to coordinate, specially when the person at
|
|
the remote host does not even know what an IP address is.
|
|
|
|
To solve this problem, Nping implements a new mode of operation, called
|
|
"Echo mode", which provides a combination of a packet generator and a
|
|
remote sniffer.
|
|
|
|
The Echo mode is based on a client/server architecture. Both ends run Nping,
|
|
one of them in server mode and the other in client mode. The way it works
|
|
is: the Nping client performs an initial handshake with the server over some
|
|
standard port (creating a side-channel). Then it notifies the server
|
|
what packets are about to be sent. The server sets up a liberal BPF
|
|
filter that captures those packets, and starts listening. When the server
|
|
receives a packet it encapsulates it (including the link layer frame)
|
|
into our own protocol packet and sends it back to the nping client.
|
|
This would be essentially like running tcpdump on the remote machine
|
|
and having it report back the packets you sent to it with Nping.
|
|
|
|
By having the side-channel to talk to the server, things like NAT would
|
|
become immediately apparent because you'd see your source IP (and
|
|
sometimes port) change. Things like "packet shapers" that change TCP
|
|
window sizes transparently between hosts would turn up. It would be
|
|
easy to tell if the traffic is being dropped in transit and never gets
|
|
to the box. It would also be easy to tell if the traffic does make it
|
|
to the box but the reply never makes it back to you.
|
|
|
|
In general, it would be like sending a postal package to someone and
|
|
having them email you a photo of the package when they get it. If you
|
|
think your packages are being abused by the parcel service then having
|
|
someone on the other end to send information back is a great way to
|
|
uncover what is going on.
|
|
|
|
|
|
|
|
2. NPING ECHO PROTOCOL SPECIFICATION
|
|
|
|
|
|
2.1 General Message Format
|
|
|
|
The following diagram describes the general format of the NEP messages.
|
|
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Version | Message Type | Total Length |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Sequence Number |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Timestamp |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Reserved |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
. .
|
|
. DATA .
|
|
. .
|
|
| |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
. .
|
|
. Message Authentication Code .
|
|
. .
|
|
| |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
|
|
There are 7 different kinds of packets:
|
|
|
|
NEP_HANDSHAKE_SERVER (S->C)
|
|
Informs the client of the highest version it supports and sends
|
|
the server's authentication parameters.
|
|
|
|
NEP_HANDSHAKE_CLIENT (C->S)
|
|
Informs the server of the highest version it supports and sends
|
|
the initial authentication parameters.
|
|
|
|
NEP_HANDSHAKE_FINAL (S->C)
|
|
Echoes server nonce back to the server.
|
|
|
|
NEP_PACKET_SPEC: (C->S):
|
|
Tells the server what kind of packets we are planning to send.
|
|
|
|
NEP_READY: (S->C):
|
|
Tells the client that the server is ready to start receiving
|
|
packets.
|
|
|
|
NEP_ECHO: (S->C):
|
|
Contains the packet that the server receives from the client.
|
|
|
|
NEP_ERROR: (C->S or S->C):
|
|
Indicates an error and terminates the session.
|
|
|
|
|
|
|
|
2.2 Field Description
|
|
|
|
Version: 8 bits
|
|
Current version of the protocol. This document covers version 0x01.
|
|
|
|
|
|
Message type: 8 bits
|
|
Integer that indicates the type of packet. It must be one of the
|
|
type codes defined in section 2.3.
|
|
|
|
|
|
Total Length: 16 bits
|
|
Length of the entire packet, measured in 32bit words. Value must
|
|
be in NETWORK byte order.
|
|
|
|
|
|
Sequence Number: 32 bits
|
|
Packet sequence number, relative to the sender. Initially this
|
|
field is set to a random value, and then it is incremented by one
|
|
for each packet that is sent in a given session. The counter must
|
|
wrap back to zero after it reaches (2^32)-1. This field is intended
|
|
to provide flow tracking and basic protection against replay
|
|
attacks.
|
|
|
|
Timestamp: 32 bits
|
|
Current time of the sender. This time is expressed as the number
|
|
of seconds elapsed since 00:00, 01/01/1970 UTC (epoch time).
|
|
|
|
Reserved: 32 bits
|
|
Reserved for future use. Reserved fields have been added for two
|
|
reasons: to allow future extension of the protocol and to make
|
|
the header a multiple of 128 bits needed to satisfy AES encryption
|
|
requirements in block size.
|
|
|
|
|
|
Data: variable length
|
|
Message specific data.
|
|
|
|
|
|
Message Authentication Code : 256 bits
|
|
Code that provides integrity and authentication to the rest of the
|
|
packet. For this, the HMAC-SHA256 suite must be used. The
|
|
computation of the code includes the whole plain-text message until
|
|
the first byte of the Message Authentication Code field.
|
|
|
|
|
|
2.3 Message type codes
|
|
|
|
Message NEP_HANDSHAKE_SERVER: 0x01
|
|
Message NEP_HANDSHAKE_CLIENT: 0x02
|
|
Message NEP_HANDSHAKE_FINAL: 0x03
|
|
Message NEP_PACKET_SPEC: 0x04
|
|
Message NEP_READY: 0x05
|
|
Message NEP_ECHO: 0x06
|
|
Message NEP_ERROR: 0x07
|
|
|
|
|
|
2.4 Message NEP_HANDSHAKE_SERVER
|
|
|
|
The NEP_HANDSHAKE_SERVER message is sent by the server and it requests
|
|
client's authentication. The packet informs the client of the latest
|
|
version of the protocol that the server supports and provides the
|
|
appropriate information for the client authentication process.
|
|
|
|
The NEP_HANDSHAKE_SERVER message establishes the following:
|
|
|
|
- The identity of the server and that the message was generated
|
|
by that server.
|
|
- That the message was intended for the client.
|
|
- The integrity and originality of the message.
|
|
|
|
|
|
The format of the NEP_HANDSHAKE_SERVER message is the following:
|
|
|
|
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Version | Message Type | Total Length |
|
|
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Sequence Number |
|
|
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Timestamp |
|
|
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Reserved |
|
|
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
5 +-- --+
|
|
| |
|
|
6 +-- --+
|
|
| |
|
|
7 +-- --+
|
|
| Server Nonce |
|
|
8 +-- --+
|
|
| |
|
|
9 +-- --+
|
|
| |
|
|
10 +-- --+
|
|
| |
|
|
11 +-- --+
|
|
| |
|
|
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
13 + --+
|
|
| |
|
|
14 +-- Reserved --+
|
|
| |
|
|
15 +-- --+
|
|
| |
|
|
16 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
. . .
|
|
. . Message Authentication Code .
|
|
|
|
. . .
|
|
| |
|
|
24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
|
|
Server Nonce: 256 bits
|
|
Random number. This number must be generated using a
|
|
cryptographically secure PRNG and must not be reused. This is
|
|
the data that should be used by the client to construct its
|
|
cipher block initialization vector.
|
|
|
|
Reserved: 120 bits
|
|
Reserved for future use.
|
|
|
|
HMAC-SHA256: 256 bits
|
|
Message authentication code that covers the entire packet, from
|
|
byte 0 to the last byte of the last reserved field. The code is
|
|
computed over the plaintext, before the encryption is applied to
|
|
part of the packet.
|
|
|
|
|
|
|
|
2.5 Message NEP_HANDSHAKE_CLIENT
|
|
|
|
|
|
The NEP_HANDSHAKE_CLIENT message is sent by the client and it provides
|
|
the appropriate information for client-side authentication. This type
|
|
of message is generated only if the previous NEP_HANDSHAKE_CLIENT
|
|
message contains a valid message authentication code.
|
|
|
|
The NEP_HANDSHAKE_CLIENT message establishes the following:
|
|
|
|
- The identity of the client and that reply message has been
|
|
generated by the client.
|
|
- That the message was intended for the server.
|
|
- The integrity and originaltity of the reply.
|
|
|
|
|
|
The format of the NEP_HANDSHAKE_CLIENT message is the following:
|
|
|
|
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Version | Message Type | Total Length |
|
|
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Sequence Number |
|
|
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Timestamp |
|
|
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Reserved |
|
|
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
5 +-- --+
|
|
| |
|
|
6 +-- --+
|
|
| |
|
|
7 +-- --+
|
|
| Server Nonce |
|
|
8 +-- --+
|
|
| |
|
|
9 +-- --+
|
|
| |
|
|
10 +-- --+
|
|
| |
|
|
11 +-- --+
|
|
| |
|
|
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
13 +-- --+
|
|
| |
|
|
14 +-- --+
|
|
| |
|
|
15 +-- --+
|
|
| Client Nonce |
|
|
16 +-- --+
|
|
| |
|
|
17 +-- --+
|
|
| |
|
|
18 +-- --+
|
|
| |
|
|
19 +-- --+
|
|
| |
|
|
20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
###################### ENCRYPTION STARTS HERE #######################
|
|
20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
21 +-- --+
|
|
| |
|
|
22 +-- Partner IP address --+
|
|
| |
|
|
23 +-- --+
|
|
| |
|
|
24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| IP Version | |
|
|
25 +---------------+ --+
|
|
| |
|
|
26 +-- Reserved --+
|
|
| |
|
|
27 +-- --+
|
|
| |
|
|
28 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
####################### ENCRYPTION ENDS HERE #######################
|
|
28 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
. . .
|
|
. . Message Authentication Code .
|
|
. . .
|
|
| |
|
|
36 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
|
|
Server Nonce: 256 bits
|
|
Nonce value received from the server in the previous
|
|
NEP_HANDSHAKE_SERVER message. This allows the server to ensure that
|
|
the received reply is fresh and was generated as a result of its
|
|
NEP_HANDSHAKE_SERVER message.
|
|
|
|
Client Nonce: 256 bits
|
|
Random number. This number must be generated using a
|
|
cryptographically secure PRNG and must not be reused. This is
|
|
the data that should be used by the server to construct its
|
|
cipher block initialization vector.
|
|
|
|
Partner IP address: 128 bits
|
|
This is the server's IP address as seen by the client. This field
|
|
has 128 bits to allow use of both IPv4 and IPv6 addresses. When
|
|
IPv4 is used, only the first four bytes are used. The rest may be
|
|
set to zero or filled with random data.
|
|
|
|
IP version: 8-bits
|
|
Version of the address in the "Partner IP address" field. It should
|
|
take one of the following values:
|
|
|
|
0x04 : for IP version 4.
|
|
0x06 : for IP version 6.
|
|
|
|
2.6 Message NEP_HANDSHAKE_FINAL
|
|
|
|
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Version | Message Type | Total Length |
|
|
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Sequence Number |
|
|
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Timestamp |
|
|
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Reserved |
|
|
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
5 +-- --+
|
|
| |
|
|
6 +-- --+
|
|
| |
|
|
7 +-- --+
|
|
| Client Nonce |
|
|
8 +-- --+
|
|
| |
|
|
9 +-- --+
|
|
| |
|
|
10 +-- --+
|
|
| |
|
|
11 +-- --+
|
|
| |
|
|
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
###################### ENCRYPTION STARTS HERE #######################
|
|
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
13 +-- --+
|
|
| |
|
|
14 +-- Partner IP address --+
|
|
| |
|
|
15 +-- --+
|
|
| |
|
|
16 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| IP Version | |
|
|
17 +---------------+ --+
|
|
| |
|
|
18 +-- Reserved --+
|
|
| |
|
|
19 +-- --+
|
|
| |
|
|
20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
####################### ENCRYPTION ENDS HERE ########################
|
|
20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
. . .
|
|
. . Message Authentication Code .
|
|
. . .
|
|
| |
|
|
28 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
|
|
Client Nonce: 256 bits
|
|
Nonce value received from the client in the preceding
|
|
NEP_HANDSHAKE_CLIENT message.
|
|
|
|
Partner IP address: 128 bits
|
|
This is the clients's IP address as seen by the server. This field
|
|
has 128 bits to allow use of both IPv4 and IPv6 addresses. When
|
|
IPv4 is used, only the first four bytes are used. The rest may be
|
|
set to zero or filled with random data. The inclusion of this
|
|
information lets the client immediately detect the presence of
|
|
some intermediate devices that change his source IP (e.g a NAT box).
|
|
This is a modification of the original X.509 three way
|
|
authentication protocol, provided, among other things, in order to
|
|
make the man-in-the-middle attack described in [1] more difficult.
|
|
|
|
IP version: 8 bits
|
|
Version of the address in the "Partner IP address" field. It should
|
|
take one of the following values:
|
|
|
|
0x04 : for IP version 4.
|
|
0x06 : for IP version 6.
|
|
|
|
|
|
2.7 Operation NEP_PACKET_SPEC
|
|
|
|
The NEP_PACKET_SPEC message is sent by the client to tell the server
|
|
what kind of packets it should expect.
|
|
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
###################### ENCRYPTION STARTS HERE #######################
|
|
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Version | Message Type | Total Length |
|
|
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Sequence Number |
|
|
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Timestamp |
|
|
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Reserved |
|
|
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| IP version | Protocol | Packet Count |
|
|
5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
. | |
|
|
. . .
|
|
. . PacketSpec .
|
|
n . .
|
|
| |
|
|
32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
####################### ENCRYPTION ENDS HERE ########################
|
|
32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
. . .
|
|
. . Message Authentication Code .
|
|
. . .
|
|
| |
|
|
40 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
IP version: 8 bits
|
|
Specifies which is the expected IP version. It must contain one
|
|
of the following values:
|
|
|
|
0x04 (IP version 4)
|
|
|
|
0x06 (IP version 6)
|
|
|
|
0xFF (Any version)
|
|
|
|
Protocol: 8 bits.
|
|
Specifies which kind of packets will be sent to the server. It
|
|
must contain one of the following values:
|
|
|
|
0x06 (Protocol TCP)
|
|
Tells the server to listen to TCP packets coming from
|
|
the client's IP address.
|
|
|
|
0x11 (Protocol UDP)
|
|
Tells the server to listen to UDP packets coming from
|
|
the client's IP address.
|
|
|
|
0x01 (Protocol ICMP)
|
|
Tells the server to listen to ICMP packets coming from
|
|
the client's IP address.
|
|
|
|
Packet count: 16 bits.
|
|
Specifies how many packets will be sent. It must be in NETWORK
|
|
byte order.
|
|
|
|
PacketSpec: 864 bits.
|
|
Tells the server which header fields should be checked to match
|
|
a captured packet with the client that sent it. This is necessary
|
|
as the server supports multiple user sessions at a time, and needs
|
|
a way to distinguish the packets.
|
|
|
|
The PacketSpec field consists of a list of protocol fields and
|
|
their expected value. Every item on that list has the following
|
|
format:
|
|
|
|
{Field Code, Field Value}
|
|
|
|
Where "Field Code" is an 8-bit numeric identifier of the field (see
|
|
definitions below) and "Field Value" is the expected value, that
|
|
the server should try to match. The length of "Field Value" depends
|
|
on the "Field Code" (see table below for details) and, in general,
|
|
it matches the usual length for that field int its original
|
|
protocol header.
|
|
|
|
Items on the PacketSpec list are specified sequentially. However,
|
|
the final length of the list must be 108 bytes, so null bytes must
|
|
be added after the last item.
|
|
|
|
The following table lists the available field specifiers, their
|
|
code and the length of their values.
|
|
|
|
====NAME======== ==CODE== ==LENGTH==
|
|
+----------------+--------+----------+
|
|
| IPv4_TOS | 0xA0 | 8 bits |
|
|
+----------------+--------+----------+
|
|
| IPv4_ID | 0xA1 | 16 bits |
|
|
+----------------+--------+----------+
|
|
| IPv4_FRAGOFF | 0xA2 | 16 bits |
|
|
+----------------+--------+----------+
|
|
| IPv4_PROTO | 0xA3 | 8 bits |
|
|
+----------------+--------+----------+
|
|
|
|
+----------------+--------+----------+
|
|
| IPv6_TCLASS | 0xB0 | 8 bits |
|
|
+----------------+--------+----------+
|
|
| IPv6_FLOW | 0xB1 | 24 bits |
|
|
+----------------+--------+----------+
|
|
| IPv6_NHDR | 0xB2 | 8 bits |
|
|
+----------------+--------+----------+
|
|
|
|
+----------------+--------+----------+
|
|
| TCP_SPORT | 0xC0 | 16 bits |
|
|
+----------------+--------+----------+
|
|
| TCP_DPORT | 0xC1 | 16 bits |
|
|
+----------------+--------+----------+
|
|
| TCP_SEQ | 0xC2 | 32 bits |
|
|
+----------------+--------+----------+
|
|
| TCP_ACK | 0xC3 | 32 bits |
|
|
+----------------+--------+----------+
|
|
| TCP_FLAGS | 0xC4 | 8 bits |
|
|
+----------------+--------+----------+
|
|
| TCP_WIN | 0xC5 | 16 bits |
|
|
+----------------+--------+----------+
|
|
| TCP_URP | 0xC6 | 16 bits |
|
|
+----------------+--------+----------+
|
|
|
|
+----------------+--------+----------+
|
|
| ICMP_TYPE | 0xD0 | 8 bits |
|
|
+----------------+--------+----------+
|
|
| ICMP_CODE | 0xD1 | 8 bits |
|
|
+----------------+--------+----------+
|
|
|
|
+----------------+--------+----------+
|
|
| UDP_SPORT | 0xE0 | 16 bits |
|
|
+----------------+--------+----------+
|
|
| UDP_DPORT | 0xE1 | 16 bits |
|
|
+----------------+--------+----------+
|
|
| UDP_LEN | 0xE2 | 16 bits |
|
|
+----------------+--------+----------+
|
|
|
|
+----------------+--------+----------+
|
|
| PAYLOAD_MAGIC | 0xFF | Variable |
|
|
+----------------+--------+----------+
|
|
|
|
|
|
The PAYLOAD_MAGIC type lets the client specify some magic number
|
|
included in the packet's payload. This can be used when all other
|
|
specifiers fail (e.g: in IPv4-to-IPv6 tunnels). The length of
|
|
its field data is variable and must be specified right after the
|
|
field code. Note that the length can never be higher than the
|
|
remaining space in the PacketSpec field. If no other field
|
|
specifiers are set, "length" can never be higher than 106 bytes.
|
|
Servers should carefully check the structure of the PacketSpec
|
|
field and close the session established with the sender if it
|
|
does not meet the requirements specified in this document.
|
|
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| PAYLOAD_MAGIC | Length | |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value +
|
|
| |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
PAYLOAD_MAGIC: 8 bits.
|
|
Field code. MUST be set to 0xFF.
|
|
|
|
Length: 8 bits.
|
|
Length of the data in the "Value" field. MUST be greater
|
|
than zero; MUST NOT be greater than the remaining space in
|
|
the PacketSpec field and MUST NEVER exceed 106 bytes.
|
|
|
|
Value: variable length.
|
|
Payload data. Its length must be the one specified in the
|
|
"Length" field. It may contain any binary value. Comparisons
|
|
at the server side should be made at the bit level so the
|
|
encoding should match the one used at the application layer
|
|
in the packets that are produced and sent by the client.
|
|
|
|
|
|
Here is an example of how a typical specifier list looks like:
|
|
|
|
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| IPv4_TOS | 0x00 | IPv4_ID | 0xCA |
|
|
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| 0xFE | IPv4_PROTO | 0x06 | TCP_SPORT |
|
|
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| 0x4432 | TCP_DPORT | 0x00 |
|
|
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| 0x50 | TCP_FLAGS | 0x08 | TCP_SEQ |
|
|
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| 0x5D33FA6D |
|
|
5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| 0x00 | 0x00 | 0x00 | 0x00 |
|
|
6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
. .
|
|
. .
|
|
. .
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| 0x00 | 0x00 | 0x00 | 0x00 |
|
|
27 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
All packet specifications MUST include the IPv4_ID specifier
|
|
(or IPv6_Flow for IPv6) and at least three other fields specifiers.
|
|
Additionally, clients MUST NEVER specify the same field specifier
|
|
more than once in a NEP_PACKET_SPEC message. Clients that send
|
|
messages that do not meet these requirements MUST be rejected by the
|
|
server.
|
|
|
|
|
|
2.8 Operation NEP_READY
|
|
|
|
The READY packet is sent by the server to indicate the client that
|
|
his SPECS packet was accepted and that everything is ready to start
|
|
receiving and echoing packets.
|
|
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
###################### ENCRYPTION STARTS HERE #######################
|
|
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Version | Message Type | Total Length |
|
|
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Sequence Number |
|
|
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Timestamp |
|
|
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Reserved |
|
|
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
####################### ENCRYPTION ENDS HERE ########################
|
|
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
. . .
|
|
. . Message Authentication Code .
|
|
. . .
|
|
| |
|
|
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
|
|
|
|
|
|
2.9 Operation NEP_ECHO
|
|
|
|
The NEP_ECHO message is sent by the server and it contains an echoed
|
|
network packet.
|
|
|
|
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
###################### ENCRYPTION STARTS HERE #######################
|
|
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Version | Message Type | Total Length |
|
|
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Sequence Number |
|
|
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Timestamp |
|
|
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Reserved |
|
|
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| DLT Type | Packet Length |
|
|
5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
. .
|
|
. . Packet .
|
|
. . .
|
|
. . +-+-+-+-+-+-+-+-+
|
|
| | Padding |
|
|
n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
####################### ENCRYPTION ENDS HERE ########################
|
|
n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
. . .
|
|
. . Message Authentication Code .
|
|
. . .
|
|
| |
|
|
n+8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
|
|
DLT Type: 16 bits.
|
|
Specifies the type of link layer device used in the server side.
|
|
Since the server includes link layer frames in echoed packets,
|
|
the client needs to know the DLT in order to process link layer
|
|
header information. Values used in this field must match DLT types
|
|
defined in libpcap and must be transmitted in NETWORK byte order.
|
|
Servers may use the special value 0x0000 to indicate that no link
|
|
layer header is included.
|
|
|
|
Packet Length: 16 bits.
|
|
Specifies the length of the echoed packet measured in bytes.
|
|
The value stored in this field must be in NETWORK byte order and
|
|
must never be greater than 9212, as that is the maximum number of
|
|
bytes that can be echoed per packet.
|
|
|
|
Packet: variable length.
|
|
This corresponds to the packet being echoed. Servers should
|
|
store the packet exactly as it was received. No byte order
|
|
conversions or any other alteration should be performed.
|
|
The whole NEP_ECHO packet must have a length that is a multiple of
|
|
16 bytes, so if (packet_len+4)mod16 is not zero, the packet field
|
|
must be padded with NULL bytes. As noted before, the maximum length
|
|
for an echoed packet is 9212 bytes. Any packet that exceeds that
|
|
length must be truncated.
|
|
|
|
|
|
|
|
2.10 Operation NEP_ERROR
|
|
|
|
The NEP_ERROR packet is sent by client or server when an error occurs,
|
|
and informs the other end that the sender is terminating the NEP
|
|
session and closing the TCP connection. This message includes an error
|
|
description string that should explain the reason why the session is
|
|
being terminated (e.g. authentication failed, invalid message format).
|
|
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
###################### ENCRYPTION STARTS HERE #######################
|
|
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Version | Message Type | Total Length |
|
|
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Sequence Number |
|
|
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Timestamp |
|
|
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Reserved |
|
|
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
. .
|
|
. . Error Message .
|
|
. . .
|
|
. . .
|
|
| |
|
|
24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
####################### ENCRYPTION ENDS HERE ########################
|
|
24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
. . .
|
|
. . Message Authentication Code .
|
|
. . .
|
|
| |
|
|
32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
Error Message: 640 bits.
|
|
Contains a NULL-terminated ASCII string that describes the reason
|
|
why the session is being terminated by the sender. The string MUST
|
|
contain a NULL character (0x00) at the end of it. The remaining
|
|
bytes, if any, must also be set to zero.
|
|
|
|
|
|
2.11 Flow diagrams
|
|
|
|
|
|
The following diagram shows a typical client/server session:
|
|
|
|
+------+ +------+
|
|
|CLIENT| |SERVER|
|
|
+------+ +------+
|
|
| |
|
|
| NEP_HANDSHAKE_SERVER |
|
|
|<<---------------------|
|
|
| |
|
|
| |
|
|
| NEP_HANDSHAKE_CLIENT |
|
|
|--------------------->>|
|
|
| |
|
|
| |
|
|
| NEP_HANDSHAKE_FINAL |
|
|
|<<---------------------|
|
|
| |
|
|
| |
|
|
| |
|
|
| NEP_PACKET_SPEC |
|
|
|--------------------->>|
|
|
| |
|
|
| |
|
|
| |
|
|
| NEP_READY |
|
|
|<<---------------------|
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
| NEP_ECHO |
|
|
|<<---------------------|
|
|
| |
|
|
| NEP_ECHO |
|
|
|<<---------------------|
|
|
| |
|
|
| NEP_ECHO |
|
|
|<<---------------------|
|
|
| . |
|
|
| . |
|
|
| . |
|
|
| NEP_ECHO |
|
|
|<<---------------------|
|
|
| |
|
|
| |
|
|
| |
|
|
| TCP Connection Close |
|
|
|<<------------------->>|
|
|
|
|
|
|
|
|
|
|
|
|
The following diagram represents a session where the client sends an
|
|
invalid PacketSpec message.
|
|
|
|
|
|
+------+ +------+
|
|
|CLIENT| |SERVER|
|
|
+------+ +------+
|
|
| |
|
|
| NEP_HANDSHAKE_SERVER |
|
|
|<<---------------------|
|
|
| |
|
|
| |
|
|
| NEP_HANDSHAKE_CLIENT |
|
|
|--------------------->>|
|
|
| |
|
|
| |
|
|
| NEP_HANDSHAKE_FINAL |
|
|
|<<---------------------|
|
|
| |
|
|
| |
|
|
| |
|
|
| NEP_PACKET_SPEC |
|
|
|--------------------->>|
|
|
| |
|
|
| |
|
|
| NEP_ERROR |
|
|
|<<---------------------|
|
|
| |
|
|
| TCP Connection Close |
|
|
|<<------------------->>|
|
|
|
|
|
|
The following diagram represents a session where the server fails to
|
|
provide a valid NEP_HANDSHAKE_SERVER message.
|
|
|
|
+------+ +------+
|
|
|CLIENT| |SERVER|
|
|
+------+ +------+
|
|
| |
|
|
| NEP_HANDSHAKE_SERVER |
|
|
|<<---------------------|
|
|
| |
|
|
| |
|
|
| TCP Connection Close |
|
|
|<<------------------->>|
|
|
|
|
|
|
|
|
The following diagram represents a session where the client fails to
|
|
provide a valid NEP_HANDSHAKE_CLIENT message.
|
|
|
|
|
|
+------+ +------+
|
|
|CLIENT| |SERVER|
|
|
+------+ +------+
|
|
| |
|
|
| NEP_HANDSHAKE_SERVER |
|
|
|<<---------------------|
|
|
| |
|
|
| |
|
|
| NEP_HANDSHAKE_CLIENT |
|
|
|--------------------->>|
|
|
| |
|
|
| |
|
|
| TCP Connection Close |
|
|
|<<------------------->>|
|
|
|
|
|
|
|
|
2.12 Security
|
|
|
|
The NEP client/server authentication process is based on the three-way
|
|
authentication protocol, described in CITT recommendation X.509 [2].
|
|
However, it has been slightly modified:
|
|
|
|
- Messages are not signed using public-key cryptography but a
|
|
symmetric encryption key known by both client and server. This
|
|
provides the same authentication as the original specification
|
|
but it does not provide non-repudiation.
|
|
|
|
- Ciphertext is encrypted using the secret key shared by client and
|
|
server, instead of using the receiver's public key.
|
|
|
|
The cipher suite to be used for data encryption is AES-128.
|
|
|
|
When one of the two participating entities receives a fully encrypted
|
|
message (any message other than NEP_HANDSHAKE_SERVER, NEP_HANDSHAKE_CLIENT
|
|
or NEP_HANDSHAKE_FINAL), it performs the following steps:
|
|
|
|
1. Reads 128 bits and decrypts them.
|
|
2. Checks that version equals 0x01
|
|
3. Checks that the value in the message type field corresponds to a
|
|
valid message type code.
|
|
4. If message type is not one of NEP_HANDSHAKE_CLIENT or
|
|
NEP_HANDSHAKE_SERVER, it checks that the received sequence number
|
|
matches the last received sequence number from the same sender plus
|
|
one.
|
|
5. It checks that the received timestamp is inside a "reasonable" time
|
|
window (where "reasonable" is left undefined on purpose, as it may
|
|
vary depending on the nature of the implementation or the host
|
|
system).
|
|
6. Checks the received total length. For messages whose length is
|
|
fixed, it should check whether the received length matches the
|
|
expected length of the message. For variable length messages, it
|
|
should check that the length is at least, higher than or equal to the
|
|
minimum length for that kind of message.
|
|
7. If all tests succeed, then the remaining bits are read
|
|
(remaining = TotalLength - 128bits)
|
|
8. Any remaining ciphertext is decrypted.
|
|
9. An alternative message authentication code is computed over the
|
|
unencrypted data and matched against the received one. If both codes
|
|
match, then the message is considered valid (its integrity has been
|
|
verified and its contents are to be trusted), authentic (the creator
|
|
of the message is someone who knows the secret) and fresh (the
|
|
message is new and has not been replayed).
|
|
|
|
|
|
2.13 Cryptographic key derivation.
|
|
|
|
Five cryptographic keys are generated for each client session. All of
|
|
them are derived from a single shared secret (a passphrase), known by
|
|
client and server. The key derivation process is the following:
|
|
|
|
h=SHA256( "passphrase" + NONCES + KEY_TYPE_ID )
|
|
do(1000 times){
|
|
h=SHA256(h);
|
|
}
|
|
|
|
Where 'h' is a 256bit buffer that holds the final key, 'SHA256' is the
|
|
hash computation function for the SHA-256 algorithm, 'NONCES' is the
|
|
combination of server's and client's nonce values, exchanged during
|
|
handshake, and KEY_TYPE_ID is a string that varies depending on the
|
|
type of key being derived. (See below for its definitions).
|
|
|
|
As mentioned above, a total of 5 symmetric keys are used. Those keys
|
|
are:
|
|
|
|
NEP_KEY_MAC_S2C : Key used by the server to sign its messages.
|
|
For this type of key, KEY_TYPE_ID="NEPkeyforMACServer2Client"
|
|
(unquoted) and 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).
|
|
|
|
NEP_KEY_MAC_S2C_INITIAL : Key used by the server to sign its
|
|
NEP_HANDSHAKE_SERVER messages. This is a special case key because
|
|
it needs to be generated before a client nonce is received (this is
|
|
the only key that is not influenced by the client's nonce). For
|
|
this type of key, KEY_TYPE_ID="NEPkeyforMACServer2ClientInitial"
|
|
(unquoted) and NONCES equals the nonce in the NEP_HANDSHAKE_SERVER
|
|
message, concatenated with an empty client nonce, in other words,
|
|
a nonce with all its bits set to zero (SERVER_NONCE + ZEROED_NONCE).
|
|
|
|
NEP_KEY_MAC_C2S : Key used by the client to sign its messages.
|
|
For this type of key, KEY_TYPE_ID="NEPkeyforMACClient2Server"
|
|
(unquoted) and 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).
|
|
|
|
NEP_KEY_CIPHERTEXT_C2S : Key used by the client to encrypt its
|
|
messages. For this type of key, KEY_TYPE_ID=
|
|
"NEPkeyforCiphertextClient2Server" (unquoted) and 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).
|
|
|
|
NEP_KEY_CIPHERTEXT_S2C : Key used by the server to encrypt its
|
|
messages. For this type of key, KEY_TYPE_ID=
|
|
"NEPkeyforCiphertextServer2Client" (unquoted) and 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).
|
|
|
|
When not all 256 bits are required, the last 256-N bits of key material
|
|
may be discarded, where N is the desired key length. This is, if less
|
|
than 256 of key material is needed, discarded bits must be the least
|
|
significant ones.
|
|
|
|
2.14 Encryption process.
|
|
|
|
Encryption must be performed using AES-128-CBC. This is, using the AES
|
|
encryption algorithm in CBC mode, with 128-bit keys.
|
|
|
|
For each party producing encrypted data, the first initialization
|
|
vector should be the nonce that this same party generated during the
|
|
authentication handshake phase. If the nonce has more bits than needed,
|
|
only the necessary number of bits should be used. These bits should be
|
|
the most significant ones.
|
|
|
|
The initialization vector for subsequent encryption operations should
|
|
be the last ciphertext block produced by the same entitiy. This is, to
|
|
encrypt the Nth message, the last ciphertext block of the (N-1)th
|
|
message should be used as the initialization vector for message N. Same
|
|
rule applies for decryption operations, where the initialization vector
|
|
should be the last ciphertext block received from the other end.
|
|
|
|
|
|
2.15 Additional considerations.
|
|
|
|
- By default, the server side will listen for incoming connections on
|
|
TCP port 9929.
|
|
|
|
|
|
3. GLOSSARY
|
|
|
|
C->S : Indicates that a given message is sent from the client to the server
|
|
S->C : Indicates that a given message is sent from the server to the client
|
|
NEP : Acronym for Nping Echo Protocol
|
|
|
|
|
|
4. REFERENCES
|
|
|
|
[1] I'Anson, C. and Mitchell, C. (1990). "Security defects in CCITT
|
|
recommendation X.509: the directory authentication framework". ACM
|
|
SIGCOMM Computer Communication Review, Volume 20, Issue 2. United
|
|
States.
|
|
|
|
[2] C.C.I.T.T. (1988). "Recommendation X .509, The Directory -
|
|
Authentication Framework"
|