[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@ietf.org
https://www1.ietf.org/mailman/listinfo/emu