4.3 Packet structure
The protocol structures are described with the notation of SSL and TLS defined in [1].
The general packet structure is:
struct {
MkeHeader header;
Payload mobileKePayloads[0..2^16-1]; /* unencrypted payloads */
Payload encryptedPayloads[0..2^16-1]; /* encrypted payloads */
} MobileKE
struct {
ProtocolVerion mobileKeVersion;
TypeOfMessage type;
Length len;
opaque cookieServer[4;,
opaque cookieClient[4];
} MkeHeader
struc {
uint8 version; /* major | minor */
} ProtocolVersion
enum {
clientHallo(1), ClientResponse(3), ServerResponse(4), serverHello(5), (255) } TypeOfMessage
struc {
uint8 fragment;
uint16 packetLength;
} Length
struc {
uint8 type;
uint8 subType;
opaque data[0..2^16-1];
} Payload
Every M-KE packer has this structure. Structures and values may be empty in some packets when there is not data for them. For example: in the ClientHello, there are no encryptedPayloads since there is not key material.
The M-KE header begins with the protocol version (ProtocolVersion) of one byte. The first 4 Most Significant Bits (MSB) indicate the major version. The major version is one in this specification. The 4 Last Significant Bits (LSB) indicate the minor version and are set to zero in this specification. In order to communicate, two hosts must use the same major version. The highest major version for the M-KE protocol is 7. The values from 8 to 16 are reserved for the M-SE protocol as described in 3.4.
The next byte value TypeOfMessage gives the general description of this message. There are four types of messages described 4.2. The following Length structure (see 4.7) contains the length of the M-KE message and optional fragment details. The first two bytes (packetLength) give the total packet length including all fragments. The maximum size is 216 -1 bytes. The fragment byte gives the fragment sequence number.
The next two values, cookieServer and cookieClient, contain 4 byte cookies. The client sets the cookieClient and the server sets the cookieServer. The values identify the messages.
They are used to pick up the right M-KE negotiation. The cookies are the same for one negotiation and must be unique for the host. The unique values assure replay protection.
4.3 Packet structure 67
Furthermore, pseudo random cookies limit simple Denial of Service attacks. Pseudo random and unique values are recommended.
A payload is a data structure containing related information, like encryption algorithms.
The payloads carry all data needed for the negotiation. The sequence of the payloads in the messages is free for the implementation. The payload has a general structure consisting of Type, SubType and Data field. The Type byte specifies the information carried in the payload, like certificate. The Subtype gives further information, such as the encoding type of the data.
It can also include value itself, like the Diffie-Hellman group number. The Data vector contains the data, like the certificate. The data field is optional, since only the existence of the payload is decisive in some cases.
The payloads are grouped in two vectors unencrypted and encrypted. Security relevant payloads are embedded in encrypted vectors, such as the ID of the user. The premise for using the encrypted vector is the existence of the shared master session key (secret). The unencrypted vector carries payloads for key derivation, like Diffie-Hellman public values and protection algorithms. The payloads are exactly defined in chapter 4.8.
4.3.1 ClientHello
The first M-KE packet sent by the Mobile Client is the ClientHello packet. It has the following structure:
struct {
MkeHeader header;
struc {
DhValuePayload clientDhValues[3..2^16-1];
ProtectionAlgPayload clientSuggestedProtectionAlg[3..2^16-1];
ProtectionAlgPayload serverRequiredProtectionAlg[3..2^16-1];
MaxAnswerTimePayload requiredMaxAnswerTime;
} UnencryptedPayloads;
struc {
/* no encrypted payloads */
} EncryptedPayloads;
} ClientHello;
struct {
ProtocolVerion mobileKeVersion;
TypeOfMessage clientHallo;
Length len;
opaque cookieServer[4]=0x00000000;
opaque cookieClient[4];
} MkeHeader;
The header contains TypeOfMessage set to clientHallo. The Mobile Client generates the cookieClient value of 4 bytes. The cookieServe is null. The Lengths is set according to 4.3.
The UnencryptedPayloads contains multiple payloads defined in 4.8. The clientDhValues contains the list of DhValuePayload payloads see 4.13.1. The client sends one payload for each DH group supported, including public values. To reduce the number of exchanged messages, DH groups are predefined with large primes and elliptic curve equations. The node must only send the group number and its public value. For example: If the client proposes four groups, then the four payloads with four public values are sent. This generates more resources, since only one group with its public values is chosen. The benefit is in reducing the number of negotiation packets, which is considered critical in a mobile environment. The
4.3 Packet structure 68
server chooses one group by responding with a single DhValuePayload containing its public value. The master session key (secret) generation of DH values is defined in 4.6.
The next vector clientSuggestedProtectionAlg, see 4.13.2, contains the protection algorithms offered by the client, i.e. encryption, integrity check and authentication. For example, the client offers authentication with a password and can send packets encrypted in CBC_AES 128 bit, integrity protection with HMAC with SHA1. The client and server agree on supported algorithms using these Payloads. There is not session key at this point and the payloads are sent in clear. The Client ID and Server ID are not sent in the first two packets since they must be protected. The singe structure ProtectionAlgPayload contains one combination for authentication, encryption and integrity protection. More combinations are set in multiple payloads.
The vector serverRequiredProtectionAlg, see 4.13.2, contains the required protection algorithms from the server. This is a list of expected algorithms, for example the client expects RSA signature authentication for the server authentication and CBC_AES 128bit, HMAC with SHA1. The separation between offered and accepted algorithms gives maximum flexibility, like server authenticates with certificate and client with password. The server chooses one combination and replies with single payload in clientSuggestedProtectionAlg and serverRequiredProtectionAlg.
The requiredMaxAnswerTime, see 4.13.3, gives the maximum packet processing time at the server, tolerated by the mobile client (see Figure 4.1). The client can omit this payload if it has not estimation of this value. Knowing an estimated value of the constant PoA of the client reduces the polling interval. For example: if the PoA change is expected to be once a day then the server can certainly take 30 sec to generate the reply.
The EncryptedPayloads structure is empty since there is not key material. The structure is listed only for completeness.
4.3.2 ServerHello
After the server receives the ClientHello packet, it creates a new M-KE negotiation entry.
It generates its cookieServer value and uses it in all packets for this negotiation. The answer structure is the following:
struct {
MkeHeader header;
select (ReplyStatus) {
case pending: /* no immediate reply possible */
struc {
PendingPayload pending;
} UnencryptedPayloads;
struc {
/* no encrypted payloads */
} EncryptedPayloads;
case replyReady: /* reply ready */
struc {
DhValuePayload serverDhValue;
ProtectionAlgPayload clientProtectionAlg;
ProtectionAlgPayload serverProtectionAlg;
} UnencryptedPayloads;
struc {
MinPoaChangeIntPayload minPoaChangeInterval;
4.3 Packet structure 69 MaxUpdateIntPayload maxUpateInterval;
select (ClientAuthenticationType){
case rsasig:
CertificateRequestPaylaad clientCertificteRequest[3..2^16-1];
case dsssig:
CertificateRequestPayload clientCertificteRequest[3..2^16-1];
case password :
ChallengePayload clientChallengeValue;
case eap
EapPayload clientEap;
case sharedsecret:
/* no payload */
}
PaddingPayload padding;
} EncryptedPayloads;
} ServerHello;
struct {
ProtocolVerion mobileKeVersion;
TypeOfMessage serverHallo;
Length len;
opaque cookieServer[4];
opaque cookieClient[4];
} MkeHeader
enum {pending, replyReady} ReplyStatus;
enum {rsasig, dsssig, password, sharedSecret, eap ,null .. 255} ClientAuthenticationType;
If the server cannot reply to the client within the maximalAnswerTime, it sends a pending payload in ServerHello. In the data field of the pending payload is given the interval for the next polling, see 4.13.4. The value subtype can be seconds or milliseconds.
If the server can reply (replyReady), it selects the desired DH group and sends the serverDhValue Payload. The clientProtectionAlg value contains the selected authentication, encryption and integrity protection for the client. The client has sent a list of possibilities and the server selects only one. The server sends serverProtectionAlg in the same principle. These payloads are unencrypted in the ServerHello message. The DH values are exchanged with these payloads and the protection algorithms set, so there is sufficient information for generation of the Master Session Key (MSK), see 4.6. It must be stresses that the Master Session Key is also considered not trusted until the DH values are not authenticated. The DH values are authenticated with exchange of the HMAC values in ClientResponse and ServerResponse.
The next payloads are encrypted, as described in 4.9. The minPoaChangeInterval value gives the minimum interval for PoA change supported by the server. The value depends on the server performance. If the client expects to move more frequently than the server supports, then it can terminate the connection. The maxUpateInterval gives the idle timeout interval before the M-SE connection is deleted. If the client does not send any authenticated M-SE packet within this interval then the session is erased. The idle timeout must be announced to the parity, i.e. the client. This is very important since one of the main tasks in the M-VPN is to achieve optimum updates as described in 7.
If the client authenticates with a signature, then the server attaches clientCertificteRequest vector. It contains multiple CertificateRequestPayloads, one for every accepted certificate authority see 4.13.8. If the client wishes to authenticate with a password then the challenge is
4.4 ClientResponse