4.13 Appendix M-KE
4.13.1 DhValuePayload
The payload carries the Diffie-Hellman (DH) public parameters.
struc {
uint8 consDhValuePayload; /* defined in 4.13.19 */
uint8 contDhGroup;
opaque dhPublicValue[0..2^16-1];
} DhValuePayload
The constDhValuePayload is byte value indicating the type of the payload see 4.13.19.
The contDhGroup is a byte from the predefined DH group from 1 to 5 (contDhGroup1 to contDhGroup5). The groups are defined in Oakley protocol [10] and additional in [11]. The dhPublicValue is the public value with a variable length, in accordance with this group.
4.13.2 ProtectionAlgPayload
enum { client (1), server(2) } Node;
struc {
uint8 constProtectionAlgPayload; /* defined in 4.13.19*/
uint8 node /* client or server */
opaque constProtectionAlgorithms<0..2^16-1>;
} ProtectionAlgPayload
The protection algorithm payload contains one combination of authentication, encryption and integrity protection algorithms. It has type constProtectionAlgPayload, see 4.13.19. One combination is stored in vector of two bytes constProtectionAlgorithms. The constant values defined in 4.13. The subtype node can be client or server, depending who should use this method. The payload can be included multiple times in one message.
4.13.3 MaxAnswerTimePayload
enum { sec (1), millisec(2) } Unit;
struc {
uint8 constMaxAnswerTimePayload; /* defined in 4.13.19*/
uint8 Unit
opaque interval<0..2^16-1>;
} MaxAnswerTimePayload
The payload gives the maximal time for processing expected by the Mobile Server. This payload is sent by the Mobile Client. This parameter is important for defining the mobility of the client. The constMaxAnswerTimePayload is defined the 4.13. The subtype Unit gives the unit, seconds or milliseconds of the interval.
4.13.4 PendingPayload
If the server cannot answer within the interval given in MaxAnswerTimePayload, then it sends a pending payload.
enum { sec (1), millisec(2) } Unit;
struc {
uint8 constPendingPayload; /* defined in 4.13.19*/
uint8 Unit
4.13 Appendix M-KE 78
opaque interval<0..2^16-1>;
} PendingPayload
The interval vector gives the interval for polling. The client repeats the request after expiration of this interval.
4.13.5 MinPoaChangeIntPayload
The MinPoaChangeIntPayload gives the minimal time interval between the PoA changes supported by the Mobile Node. In this way, the client and server avoid connection drops due to low performance of the nodes. The structure is very similar to the MaxAnswerTimePayload.
enum { sec (1), millisec(2) } Unit;
struc {
uint8 constMinPoaChangeIntPayload; /* defined in 4.13.19 */
uint8 Unit
opaque interval<0..2^16-1>;
} MinPoaChangeIntPayload
4.13.6 MaxUpdateIntPayload
The payload provides information about the idle timeout used for the M-SE connection.
The node must send M-SE location update or authenticate packets maximal at this interval.
Otherwise, the session will be deleted. Announcing this value helps to adjust the best update frequency for the connection update.
enum { sec (1), millisec(2) } Unit;
struc {
uint8 constMaxUpdateIntPayload; /* defined in 4.13.19 */
uint8 Unit
opaque interval<0..2^16-1>;
} MaxUpdateIntPayload
4.13.7 SessionLifetimePayload
The payload gives information on the M-SE session lifetime. The LifetimeUnit can be seconds, MBytes or KBytes. Multiple payloads can be combined.
enum { sec (1), KBytes(2), MBytes(3) } LifetimeUnit;
struc {
uint8 constSessionLifetimePayload /* defined in 4.13.19 */
uint8 LifetimeUnit
opaque values<0..2^16-1>;
} SessionLifetimePayload;
4.13.8 CertificateRequestPayload
The node requires a certificate issued by authority pointed in this payload. The payload contains the Distinguished Name of the Certification Authority, thus the certificate subject name. The encoding can only be DER in this payload type. If there are no preferences for Certification Authority, then the node can send an empty data value for certificateDN.
The Mobile Client and Mobile Server send separate CertificateRequestPayloads to each other and therefore, they may authenticate with certificates issued by different authorities.
4.13 Appendix M-KE 79
enum { PKCS #7 (1), DER (2), ShaAndURL(3)} Encoding;
struc {
uint8 constCertificateRequestPayload /* defined in 4.13.19 */
uint8 Encoding
opaque certificateDN[0..2^16-1];
} CertificateRequestPayload;
4.13.9 CertificatePayload
This payload carries the node’s certificate. The encoding in the subtype can be DER, PKCS #7 (certificate chain) or URL. In the URL encoding, the node sends 20 octets SHA1 of the certificate followed by a URL link where the whole certificate can be loaded.
enum { PKCS #7 (1), DER (2), ShaAndURL(3)} Encoding;
struc {
uint8 constCertificatePayload /* defined in 4.13.19 */
uint8 Encoding
opaque certificate[0..2^16-1];
} CertificatePayload;
4.13.10 ChallengePayload
The payload is used for password authentication very similar to PPP CHAP[7]. External AAA servers can be used in same way as by CHAP without any change of Radius protocol.
The subtype is provided depending if the data is a challenge or response and calculated with MD5(default) or with SHA1.
enum { Challenge7 (1), ResponseMD5 (2), ResponseSHA(3)} DataType;
struc {
uint8 constChallengePayload /* defined in 4.13.19 */
uint8 DataType;
opaque value[0..2^16-1];
} ChallengePayload;
4.13.11 EapPayload
struc {
uint8 constEapPayload; /* defined in 4.13.19 */
uint8 0;
opaque eapValues[0..2^16-1];
} EapPayload;
M-KE specifies a container for EAP values as specified in [8]. Every type of EAP can be used, see 4.12.
4.13.12 PaddingPayload
struc {
uint8 consPaddingPayload; /* defined in 4.13.19 */
uint8 0;
opaque padding[0..2^16-1];
} PaddingPayload;
4.13 Appendix M-KE 80
The payload adds padding to the EncrypredPayloads, so it can be encrypted with block encryption algorithms, see 4.9.
4.13.13 IdPayload
enum { DN (1), UTF8(2), URI(3), FQDN(4) } IdType;
struc {
uint8 constIdPayload /* defined in 4.13.19 */
uint8 IdType;
opaque value[0..2^16-1];
} IdPayload;
The ID type can be Distinguished Name (DN) in DER format, String in UTF8 string format, Fully Qualified Domain Name (FQDN) or Universal Resource Identifier (URI).
4.13.14 SessionIdPayload
This payload contains one session ID. The sub type is not used. The ID value is 4 bytes.
struc {
uint8 constSessionId /* defined in 4.13.19 */
uint8 0;
opaque sessionID<0..2^32-1>;
} SessionIdPayload;
4.13.15 TrafficSelectorPayload
The traffic selector contains the transport parameter. The subtype NetworkType gives the type of the protocol. The NetworkValues contains the port ranges. If there is a single port then the start and stop values are equal. There are no port values for ICMP.
enum { TCP (1), UDP(2), ICMP(3), SCTP(3), all(4) } NetworkProtocol;
struc{
select (NetworkProtocol) { case ICMP:
/* no additional parameter */
case TCP || UDP || SCTP
uint16 startSourcePort;
uint16 stopSourcePort;
uint16 startDestPort;
uint16 stopDestPort;
}
} NetworkValues
struc {
uint8 constTrafficSelectorPayload /* defined in 4.13.19 */
uint8 NetworkProtocol;
opaque NetworkValues;
} TrafficSelectorPayload;
4.13.16 HmacPayload
The HmacPayload contains protected hash values (HMAC) of all M-KE messages sent by the client and the server excluding the pending and retransmissions. The HMAC function is well known and it is used in IPSec and TLS/SSL and described in [12]. The HMAC value
4.13 Appendix M-KE 81
is built with the hash type of MD5 or SHA1, specified in the HashType variable. The general structure:
enum { MD5 (1), SHA1(2), } HashType
struc {
uint8 constHmacPayload /* defined in 4.13.19 */
uint8 HashType;
opaque hmac[0..2^32-1];
} HmacPayload;
The input text for the HMAC is a general concatenation of all significant packets:
Tex t= Node | ClientHello | ClientResponse1 | ClientResponse2 ....| ServerHello | ServerResponse1 |
| ServerResponse2 ....
The Node string is equal to “1111” for the Mobile Client (MC) and “5555” for the Mobile Server (MS). The constants are set randomly, thus the only requirements are to be different at the MC and MS. The result is different HMAC values even when hashing the same messages at MC and MS. Mirroring attacks are avoided in this way. The retransmitted and pending messages are ignored and not considered. Retransmissions are result of packet losses or pending status. For the calculation of HMAC, all bytes of the fixed length HMAC payload are set to zero.
The EAP authentication can require more than 4 messages. In this case, all ClientResponse and ServerResponce messages are used in the HMAC building
The building of the HMAC depends on the authentication algorithm. The general principle is - if the sender has a private key then it signs the HMAC with it. The HMAC has null key in this case. If there is a shared secret or a Master Session Key (MSK) by the EAP, so it is used in the HMAC. The HMAC can be build with zero key, if no key is available.
This is strongly undesired, because of man-in-the-middle attacks. The bytes of the key are repeated until the required size is reached if the HMAC key is less than the length of the hash function (SHA1 20 bytes MD5 16Byte). For example: if the key is 17 bytes and a 20 byte key is required then the first 3 bytes are added again at the end of the key, thus the result is one 20 byte key. The HMAC for the different authentication scenario are summarized to:
Case I
The Mobile Client authenticates with a password or EAP without MSK. The Mobile Server authenticates with digital signature (RSA or DSS). The HMAC by server and client is built with zero key (equal to zero, thus no key). The client sends the HMAC result as it is.
The server signs its HMAC with its private key.
The HMAC sent by the server cannot be manipulated, since it is signed with private key.
A man-in-the-middle attack will be noticed by the HMAC verification at the client. It contains all client and server messages. The server cannot detect manipulation, since the client’s HMAC is not protected. The trust lies on the client.
Using the password as a key by calculation of the HMAC is unsuitable. The verifier of the HMAC must know the password. Commonly, the password is unknown to the M-KE server. The password is verified by external AAA server. The M-KE server forwards the CHAP values for verification to the AAA server (radius). The AAA responds with accepted or rejected to the K-KE node. The AAA cannot currently verify the HMAC, since it is not standard Radius operation. The M-KE server cannot verify the HMAC without the password in clear.
4.13 Appendix M-KE 82
Case II
The Mobile Nodes use shared secret or EAP with a derivation of the Master Session Key (MSK, see EAP). The client and the server use the MSK or the shared secret for a key in the HMAC function. The secrets are unknown to a potential man-in-the-middle attacker, thus no manipulation is possible. It must be stressed that the MSK value must be delivered with an authentication in EAP handshake.
Case III
The server authenticates himself with a password or EAP and the client with a digital signature (RSA or DSS). It is the inverse case of the first one. The HMAC is built from the input text with no key. The server sends the resulting HMAC as it is. The client signs the result with its private key.
Case IV
The client and server use passwords or EAP without a Master Session Key. This combination is highly undesirable, since there is no protection against a man-in-the-middle. If used, the HMAC is built without a key from the input text.
Case V
Both client and server use a signature. Then the HMAC is built without a key and signed with the private key of the sender.
4.13.17 NotificationPayload
enum { request (1), responce(2) } NoticationDirection;
struc {
uint8 constNotificationPayload /* defined in 4.13 */
uint8 NotificationDirection;
opaque NotificationMessage[0..2^16-1];
} NotificationPayload;
The payload carries the notification NoticationMessage the structure of which is described in 4.10. The type of the message can be a request or response. The initiator sends a notification request and the responder replies.
4.13.18 Protection algorithms
The protection algorithms are coded in two bytes shown in Figure 4.3. The first four Most Significant Bits (MSB) define the authentication. The following 4 bits define the encryption method. The next two bits define the hash function used in the HMAC. The last significant bit defines the mode of operation native or tunnel mode (M in figure).
The following values are used:
Authentication
Value Algorithm Standard
1 Digital signature RSA PKCS1[5]
2 Digital signature DSS DSS[6]
3 Password M-KE
Figure 4.3: Protection algorithms
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1
Authent. Encryption Hash Reserved M
4.13 Appendix M-KE 83
4 Shared secret M-KE
5 EAP EAP[8]
6 Null
4.13.19 Payload constants
The type byte of the payload has the values:
constDhValuePayload 1
constProtectionAlgPayload 2 constmaxAnswerTimePayload 3
constPendingPayload 4
constMinPoaChangeIntPayload 5 constMaxUpdateIntPayload 6 constCertificateRequestPayload 7 constCertificatePayload 8 constChallengePayload 9
constEapPayload 10
constPaddingPayload 11
constIdPayload 12
constSessionIdPayload 13 constTrafficSelectorPayload 14
constHmacPayload 15
constNotificationPayload 16
Encryption
Value Algorithm RFC
1 DES CBC RFC 2405
2 3DES CBC RFC 2451
3 AES 128 CBC RFC 3602
4 AES 192 CBC RFC 3602
5 AES 256 CBC RFC 3602
6 Null
Hash
Value Algorithm RFC
1 HMAC SHA RFC 2104
2 HMAC MD5 RFC 2104
Mode (M)
Value Algorithm Standard
1 Tunnel M-SE
2 Native M-SE
4.13 Appendix M-KE 84
The subtype bytes have values, which are defined in the payload definition, depending on the payload type, see chapter 4.8.
The notificationType in 4.10 has the possible values defined in the following table. The taken action depends on the local security policy. In the table are given some possible actions.
Notification
Type Meaning Originator Description
1 Server Discovery client The client requires a list of servers. The server should reply with its list.
2 Redirection to alternative
server server The client must connect server from the list.
3 M-SE session is about to expire client/server The node is about the delete the current session.
The node should start new M-KE.
4 Invalid M-SE client/server The M-SE session is invalid.
5 Node is going down client/server The node cannot serve this session anymore. The receiver must delete its sessions.
6 Node internal error client/server The node cannot serve this request due an internal error.
7 No proposal chosen server No proper proposal can be found.
8 Invalid signature client/server The node signature is invalid.
9 Revoked certificate client/server The send certificate is revoked.
10 Authentication failed client/server The credentials are invalid, i.e. password or shared secret.
11 DH parameter not supported client/server The DH group is not supported.
12 Decryption failed client/server The host cannot decrypt the payloads.
13 Server running on this client client The node also runs a server. The new server can be added in the list.