[Emu] Review of draft-clancy-emu-eap-shared-secret-01
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Emu] Review of draft-clancy-emu-eap-shared-secret-01
At 12:41 AM 7/10/2006, you wrote:
EMU Working Group T. Clancy
Internet-Draft LTS
Expires: December 28, 2006 H. Tschofenig
Siemens
June 26, 2006
EAP Generalized Pre-Shared Key (EAP-GPSK)
draft-clancy-emu-eap-shared-secret-01.txt
<snip>
1. Introduction
EAP Generalized Pre-Shared Key (EAP-GPSK) is an EAP method defining a
generalized pre-shared key authentication technique. Mutual
authentication is achieved through a nonce-based exchange that is
secured by a pre-shared key.
At present, several pre-shared key EAP methods are specified, most
notably
o EAP-PAX [I-D.clancy-eap-pax]
o EAP-PSK [I-D.bersani-eap-psk]
o EAP-TLS-PSK [I-D.otto-emu-eap-tls-psk] and
o EAP-SAKE [I-D.vanderveen-eap-sake].
Each proposal has its particular benefits but also its particular
deficiencies. EAP-GPSK is a new EAP method that tries to combine the
most valuable characteristics of each of these methods and therefore
attempts to address a broad range of usage scenarios.
The main design goals of EAP-GPSK are
Simplicity:
EAP-GPSK should be easy to implement and therefore quickly
available.
Wide applicability:
EAP-GPSK has been designed in a threat model where the attacker
has full control over the communication channel. This is the EAP
threat model that is presented in Section 7.1 of [RFC3748]. Thus,
it is particularly suited for wireless or battery powered devices.
I am not sure about the conclusion from the threat model. Are we
saying wired networks are less likely to have adversaries with full
control over the communication channel? Why go there?
Efficiency:
EAP-GPSK does not make use of public key cryptography and fully
relies of symmetric cryptography. The restriction on symmetric
cryptographic computations allows for low computational overhead.
Hence, EAP-GPSK is lightweight and well suited for any type of
device, especially those with little processing power and memory.
Flexibility:
EAP-GPSK offers cryptographic flexibility. At the beginning, the
EAP server selects a set of cryptographic algorithms and key
sizes, a so called ciphersuite. The current version of EAP-GPSK
comprises two ciphersuites, but additional ones can be easily
added.
Do we mean server proposes a suite of algms and the client selects
one? We probably need to think about the ciphersuite thing a
bit. Perhaps the IKEv2 like approach of the base protocol nailed
down in a document and have a "living" RFC that updates ciphersuites
as necessary.
Clancy & Tschofenig Expires December 28, 2006 [Page 4]
Internet-Draft EAP-GPSK June 2006
Extensibility:
The design of EAP-GPSK allows to securely exchange information
between the EAP peer and the EAP server using protected data
fields. These fields might, for example, be used to exchange
channel binding information or to provide support for identity
confidentiality.
2. Terminology
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119].
This section describes the various variables and functions used in
the EAP-GPSK method.
Variables:
PD_Payload_X:
Data carried within the X-th protected data payload
CSuite_List:
An octet array listing available ciphersuites (variable length)
CSuite_Sel:
Ciphersuite selected by the client (1 octet or 7 octets)
ID_Client:
Client NAI [RFC2486bis]
Do we expect anything other than NAI?
ID_Server:
Server identity as an opaque blob.
KS:
Integer representing the key size in octets of the selected
ciphersuite CSuite_Sel
I am not sure about using one KS per the CSuite_Sel, but we'll come
to that later.
<snip>
Clancy & Tschofenig Expires December 28, 2006 [Page 6]
Internet-Draft EAP-GPSK June 2006
MAC_X(Y).
X[A..B]:
Notation representing octets A through B of octet array X
The following abbreviations are used for the keying material:
PK:
Session key generated from the MK and used during protocol
exchange to encrypt protected data (size defined by ciphersuite)
Expanding these might be useful. What are PK and SK?
SK:
Session key generated from the MK and used during protocol
exchange to prove knowledge of PSK (size defined by ciphersuite)
<snip>
EAP-GPSK performs mutual authentication between EAP peer ("Client")
and EAP server ("Server") based on a pre-shared key (PSK). The
protocol consists of two EAP message exchanges, in which both sides
o exchange nonces and their identities and
o compute and exchange a Message Authentication Code (MAC) over the
previously exchanged values, keyed with the pre-shared key. This
MAC is considered as proof of possession of the pre-shared key.
They engage in Key derivation.
Mutually authenticate each other
(definitely not in that order, but you get the idea).
The full EAP-GPSK protocol is as follows:
GPSK-1:
ID_Server, RAND_Server, CSuite_List
Clancy & Tschofenig Expires December 28, 2006 [Page 8]
Internet-Draft EAP-GPSK June 2006
GPSK-2:
SEC_SK(ID_Client, ID_Server, RAND_Client, RAND_Server,
CSuite_List, CSuite_Sel [, ENC_PK(PD_Payload_1), ... ] )
GPSK-3
SEC_SK(RAND_Client, RAND_Server, CSuite_Sel [,
ENC_PK(PD_Payload_2) ] )
GPSK-4:
[ SEC_SK(ENC_PK(PD_Payload_3)) ]
So, are we talking about 3 message exchange and 4 message exchange,
depending on whether there is a PD_Payload_3? Or, are we talking
about the possibility of sending an empty GPSK-4?
The EAP server begins EAP-GPSK creating a random number RAND_Server
and by encoding the supported ciphersuites into CSuite_List. A
ciphersuite consists of an encryption algorithm, a key derivation
function and a message authentication code.
You mean MAC algorithm?
In GPSK-1, the EAP server sends its identity ID_Server, a random
number RAND_Server and the identifier of the chosen ciphersuite. The
decision which ciphersuite to use is policy-dependent and therefore
outside the scope of this document.
The description above sounds wrong. The server sends a CSuite_List
(as per the paragraph before), and not a chosen ciphersuite.
In GPSK-2, the peer sends its identity ID_Client, a random number
RAND_Client. Furthermore, it repeats the received parameters of the
GPSK-1 message and computes a Message Authentication Code over all
these parameters.
It also sends the chosen ciphersuite!
The EAP server verifies the received Message Authentication Code. In
case of successful verification, the EAP server computes a Message
Authentication Code over the session parameter and returns it to the
MAC over the session parameter? Please explain that.
client (within GPSK-3). Within GPSK-2 and GPSK-3, peer and EAP
server have the possibility to exchange encrypted protected data
parameters.
It looks like GPSK-4 also contains protected data (PD_Payloads, right?).
The peer verifies the received Message Authentication Code. If the
verification is successful, GPSK-4 is prepared. This message can
optionally contain the client's protected data parameters.
Could it be empty otherwise?
Upon receipt of GPSK-4, the server assures that the peer has derived
How does the server assure the peer? By sending the EAP success?
session keys SK and PK properly. Then, the EAP server sends an EAP
Success message to indicate the successful outcome of the
authentication.
Clancy & Tschofenig Expires December 28, 2006 [Page 9]
Internet-Draft EAP-GPSK June 2006
4. Key Derivation
EAP-GPSK provides key derivation in compliance to the requirements of
[RFC3748] and [I-D.ietf-eap-keying].
The long-term credential shared between EAP peer and EAP server
SHOULD be a strong pre-shared key PSK of at least 16 bytes, though
its length and entropy is variable. while it is possible to use a
password or passphrase, doing so is NOT RECOMMENDED as it would make
EAP-GPSK vulnerable to dictionary attack.
Rewrite as "Use of a password or passphrase is NOT RECOMMENDED as it would make
EAP-GPSK vulnerable to dictionary attack."
During an EAP-GPSK authentication, a Master Key MK, a Session Key SK
and a Protected Data Encryption Key PK are derived using the
ciphersuite-specified KDF and the entropy exchanged during the
execution of the protocol.
I am getting the feeling that we need to rename the keys. At the
moment the SK and PK naming is not intuitive to me. Why can't we
call them integrity and encryption keys (please feel free to stick
something in front of each).
In case of successful completion, EAP-GPSK derives and exports an MSK
and EMSK both in length of 64 byte. This keying material is derived
using the ciphersuite-specified KDF as follows:
o Entropy = RAND_Client || RAND_Server || ID_Client || ID_Server
o MK = KDF_Zero-String (PL || PSK || CSuite_Sel || Entropy)[0..KS-1]
o SK = KDF_MK (Entropy)[128..127+KS]
o PK = KDF_MK (Entropy)[128+KS..127+2*KS]
This seems to assume that KS is the size of the MK, SK and PK. Given
that the SK is for integrity and PK is for encryption, we can't make
that assumption.
o MSK = KDF_MK (Entropy || KDFData_Client || KDFData_Server)[0..63]
o EMSK = KDF_MK (Entropy || KDFData_Client ||
KDFData_Server)[64..127]
Please re-order the list. MSK, EMSK, SK and PK in that order as the
keymat seems to be drawn in that order. While we are it, why do the
SK and the PK have to start at the 128 octet? The inputs the KDF are
different. Perhaps this needs to be better designed.
o MID = KDF_Zero-String ("Method ID" || EAP_Method_Type ||
CSuite_Sel || Entropy)[0..15]
Note that the term 'Zero-String' refers to a sequence of 0x00 values,
KS octets in length. EAP_Method_Type refers to the integer value of
the IANA allocated EAP Type code.
Where is the Zero-String being used as input in the MK derivation?
From below, is it the first input?
<snip?
5. Ciphersuites
The design of EAP-GPSK allows cryptographic algorithms and key sizes,
called ciphersuite, to be negotiated during the protocol run. The
ability to specify block-based and hash-based ciphersuites is
Not sure I understand this. Are hash-based ciphersuites non-block-based?
offered. Extensibility is provided with the introduction of new
ciphersuites; this document specifies an initial set. The CSuite/
Specifier column in Figure 3 uniquely identifies a ciphersuite.
For a vendor-specific ciphersuite the first three octets are the
vendor-specific OID, and the last three octets are vendor assigned
for the specific ciphersuite.
The following ciphersuites are specified in this document:
Clancy & Tschofenig Expires December 28, 2006 [Page 11]
Internet-Draft EAP-GPSK June 2006
+-----------+----+-------------+---------------+--------------------+
| CSuite/ | KS | Encryption | Integrity | Key Derivation |
| Specifier | | | | Function |
+-----------+----+-------------+---------------+--------------------+
| 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 | GKDF-128 |
+-----------+----+-------------+---------------+--------------------+
| 0x000002 | 32 | NULL | HMAC-SHA256 | GKDF-256 |
+-----------+----+-------------+---------------+--------------------+
Doesn't EAX include a MAC? Are you showing CMAC there for completeness?
Cipher Suite 2 doesn't support protected data payloads, why?
Figure 3: Ciphersuites
Ciphersuite 1, which is based on AES as a cryptographic primitive, is
mandatory to implement.
Each ciphersuite needs to specify a key derivation function. The
ciphersuites defined in this document make use of the Generalized Key
Distribution Function (GKDF). Future ciphersuites can use any other
formally specified KDF that takes as arguments a key and a seed or
entropy value, and produces at least 1024+2*KS bits of output.
If GKDF is invoked by a MAC-based ciphersuite, then the variable
"size" contains the MAC output size in octets. In case of a block
cipher-based ciphersuite, "size" contains the block size in octets.
GKDF has the following structure:
GKDF-X(Y, Z)
X length, in octets, of the desired output
Y secret key used to protect the computation
Z data specific for the protocol run
GKDF-X (Y, Z)
{
n = int( X / size - 1 ) + 1; /* determine number of
output blocks */
M_0 = "";
result = "";
for i=1 to n {
M_i = MAC_Y (M_{i-1} || Z || i || X);
s/MAC/PRF
Are we inventing a KDF here? Why not use PRF+?
result = result || M_i;
}
return truncate (result; X)
}
Clancy & Tschofenig Expires December 28, 2006 [Page 12]
Internet-Draft EAP-GPSK June 2006
Note that the variables 'i' and 'X' in M_i are represented as 16-bit
values in network byte order.
6. Ciphersuites Processing Rules
6.1. Ciphersuite #1
6.1.1. Encryption
With this ciphersuite all cryptography is built around a single
cryptographic primitive, AES-128. Within the protected data frames,
AES-128 is used in EAX mode of operation. Ciphersuite 1 makes use of
the EAX mode of encryption. EAX is an Authenticated-Encryption-With-
Associated-Data (AEAD) scheme. It has as input a plaintext M, a
header H and a nonce N and is keyed with a key K. The idea is that
both M and H are integrity protected, but only M is encrypted.
Therefore, EAX encryption returns the ciphertext, which consists of H
and encrypted M, and a cryptographic checksum Tag T.
H || C || T = EAX.Encrypt (K; N, H, M)
H || M = EAX.Decrypt (K; N, H, C, T)
EAX strongly relies on CMAC and is therefore suited to be used in
combination with this.
The following instantiation is used:
E = C || T = EAX.Encrypt (SK; Input), where Input refers to the
following content:
o Value of PD_Payload_1 in message GPSK-2
o Value of PD_Payload_2 in message GPSK-3
o Value of PD_Payload_3 in message GPSK-4
So, the PD_Payload is integrity protected twice then?
6.1.2. Integrity
Ciphersuite 1 uses CMAC as Message Authentication Code. CMAC is
recommended by NIST. Among its advantages, CMAC is capable to work
with messages of arbitrary length. A detailed description of CMAC
can be found in [CMAC].
The following instantiation is used: AES-128-CMAC(SK, Input) denotes
the MAC of Input under the key SK.
where Input refers to the following content:
Clancy & Tschofenig Expires December 28, 2006 [Page 13]
Internet-Draft EAP-GPSK June 2006
o Value of SEC_SK in message GPSK-2
o Value of SEC_SK in message GPSK-3
o Value of SEC_SK in message GPSK-4
I know what you mean, but we need to specify this better. Is it the
input to SEK_SK?
6.1.3. Key Derivation
This ciphersuite instantiates the KDF in the following way:
MK = GKDF-16 (PSK[0..15], RAND_Client || RAND_Server || ID_Server ||
ID_Client)
KDF_out = GKDF-160 (MK, RAND_Client || RAND_Server || ID_Server ||
ID_Client)
This might be inconsistent with the earlier definition.
MSK = KDF_out[0..63]
EMSK = KDF_out[64..127]
SK = KDF_out[128..143]
PK = KDF_out[144..159]
MID = GKDF-16 (Zero-String, "Method ID" || EAP_Method_Type ||
RAND_Client || RAND_Server || ID_Server || ID_Client)
<snip>
Clancy & Tschofenig Expires December 28, 2006 [Page 14]
Internet-Draft EAP-GPSK June 2006
o Value of SEC_SK in message GPSK-2
o Value of SEC_SK in message GPSK-3
o Value of SEC_SK in message GPSK-4
6.2.3. Key Derivation
This ciphersuite instantiates the KDF in the following way:
MK = GKDF-32 (PSK, RAND_Client || RAND_Server || ID_Server ||
ID_Client || CSuite_Sel)
The PSK length is missing here. Should be 32 bytes?
KDF_out = GKDF-192 (MK, RAND_Client || RAND_Server || ID_Server ||
ID_Client)
MSK = KDF_out[0..63]
EMSK = KDF_out[64..127]
SK = KDF_out[128..159]
PK = KDF_out[160..191]
MID = GKDF-16 (Zero-String, "Method ID" || EAP_Method_Type ||
RAND_Client || RAND_Server || ID_Server || ID_Client)
<snip
Need an editorial pass!
Lakshminath
_______________________________________________
Emu mailing list
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
