Subject: [Emu] Review of draft-clancy-emu-eap-shared-secret-01

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 12 Jul 2006 05:49:48 -0700

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

---

From: "M. Vanderveen" <[email-masked]>
Date: Wed, 12 Jul 2006 09:50:15 -0700 (PDT)

I agree with Lakshminath regarding the point about having actual ciphersuites in a different RFC, so they can be updated. 
   
  Personally I'm somewhat disappointed that AES-EAX was chosen, even though it's fame is that is simpler than CCM, which is what 802.11i proposes. Not having participated in the discussions on algorithm selection, I am wondering if anybody have given thought to what can be done to help the power and memory-limited mobile, who now has to have *hardware* to please everybody: the EAP for network access, SAP 4-way handshake for link-layer access, MobileIP for mobility, VPN to sooothe operator concerns, etc, to name a few possibilities. Not all of these must be done in hw, of course. What do the implementors have to say about these?
   
  Michaela

 		
---------------------------------
Do you Yahoo!?
 Next-gen email? Have it all with the  all-new Yahoo! Mail Beta.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 12 Jul 2006 10:17:31 -0700

Michaela,

Please feel free to start the discussion on algorithm selection.  The 
DT output is just "one" opinion.  If there is an argument for or 
against the choices of algorithms, the WG I am sure would want to hear it.

I am not entirely sure CCM is the right mode, but I am open to discuss that.

Lakshminath

At 09:50 AM 7/12/2006, M. Vanderveen wrote:
>I agree with Lakshminath regarding the point about having actual 
>ciphersuites in a different RFC, so they can be updated.
>
>Personally I'm somewhat disappointed that AES-EAX was chosen, even 
>though it's fame is that is simpler than CCM, which is what 802.11i 
>proposes. Not having participated in the discussions on algorithm 
>selection, I am wondering if anybody have given thought to what can 
>be done to help the power and memory-limited mobile, who now has to 
>have *hardware* to please everybody: the EAP for network access, SAP 
>4-way handshake for link-layer access, MobileIP for mobility, VPN to 
>sooothe operator concerns, etc, to name a few possibilities. Not all 
>of these must be done in hw, of course. What do the implementors 
>have to say about these?
>
>Michaela
>
>Next-gen email? Have it all with the 
><http://us.rd.yahoo.com/evt=42241/*http://advision.webevents.yahoo.com/handraisers>all-new 
>Yahoo! Mail Beta.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 12 Jul 2006 13:16:06 -0400

Hi Michaela,

> ciphersuites in a different RFC, so they can be updated.

I don't agree. Why would this be useful? You then have to read two 
documents to implement the EAP method. It would be the same as putting 
the packet format in another document.

New ciphersuites can be added later. They would be in a separate document.

> selection, I am wondering if anybody have given thought to what can be 
> done to help the power and memory-limited mobile, who now has to have 
> *hardware* to please everybody: the EAP for network access, SAP 4-way 
> handshake for link-layer access, MobileIP for mobility, VPN to sooothe 
> operator concerns, etc, to name a few possibilities. Not all of these 
> must be done in hw, of course. What do the implementors have to say 
> about these?
There was a discussion about this issue during today's meeting. There 
was indeed tendency to avoid EAX usage and focus on CCM instead.

Ciao
Hannes

>  
> Michaela
> 
> */Lakshminath Dondeti <[email-masked]>/* wrote:
> 
>      >
> ------------------------------------------------------------------------
> Do you Yahoo!?
> <http://us.rd.yahoo.com/evt=42241/*http://advision.webevents.yahoo.com/handraisers> 
> 
> 
> 
> ------------------------------------------------------------------------
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 12 Jul 2006 13:46:36 -0400

I agree that a discussion about the algorithms is good.
Moving them into a separate document isn't.

Lakshminath Dondeti wrote:
> Michaela,
> 
> Please feel free to start the discussion on algorithm selection.  The DT 
> output is just "one" opinion.  If there is an argument for or against 
> the choices of algorithms, the WG I am sure would want to hear it.
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 12 Jul 2006 10:55:56 -0700

>I agree that a discussion about the algorithms is good.

At some point in the near future I will try and argue about 
algorithms :).  I hope to see others' proposals and views in the meanwhile.

>Moving them into a separate document isn't.

So I am drawing from the experience of IKEv2 and ESPv3.  The idea is 
purely based on document maintenance process.  If the algorithms are 
in a separate document, rev'ving them is easier without the worry of 
revising the based protocol itself.  Anyway, we don't have to discuss 
this to death.  If other folks feel the same way, they'll speak up, 
but otherwise, I am happy to let it die.

Lakshminath

>>Please feel free to start the discussion on algorithm 
>>selection.  The DT output is just "one" opinion.  If there is an 
>>argument for or against the choices of algorithms, the WG I am sure 
>>would want to hear it.
>>>though it's fame is that is simpler than CCM, which is what 
>>>802.11i proposes. Not having participated in the discussions on 
>>>algorithm selection, I am wondering if anybody have given thought 
>>>to what can be done to help the power and memory-limited mobile, 
>>>who now has to have *hardware* to please everybody: the EAP for 
>>>network access, SAP 4-way handshake for link-layer access, 
>>>MobileIP for mobility, VPN to sooothe operator concerns, etc, to 
>>>name a few possibilities. Not all of these must be done in hw, of 
>>>course. What do the implementors have to say about these?
>>>
>>>Michaela
>>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 12 Jul 2006 14:05:36 -0400

Hi Lakshminath,

Lakshminath Dondeti wrote:
> At some point in the near future I will try and argue about algorithms 
> :).  I hope to see others' proposals and views in the meanwhile.

Good. Looking forward to it.

During the mailing list discussions I proposed to recycle some of the 
IKEv2 algorithms. Maybe that's something we should be doing again.
RFC 4307 would be a good pointer.

> purely based on document maintenance process.  If the algorithms are in 
> a separate document, rev'ving them is easier without the worry of 
> this to death.  If other folks feel the same way, they'll speak up, but 
> otherwise, I am happy to let it die.
I am not sure whether IKEv2 or ESPv3 is a good example. Our goal was to 
develop a simple EAP method. To have something interoperable we have to 
define a mandatory to implement ciphersuite. I strongly believe that we 
have to put this ciphersuite into the EAP method document.

If you have to revise the mandatory to implement ciphersuite (because it 
is broken) then you must create a new EAP method document.

Ciao
Hannes

---

From: Charles Clancy <[email-masked]>
Date: Sat, 15 Jul 2006 18:30:08 -0400

>> purely based on document maintenance process.
 >
 > I am not sure whether IKEv2 or ESPv3 is a good example. Our goal was
 > to develop a simple EAP method. To have something interoperable we
 > have to define a mandatory to implement ciphersuite. I strongly
 > believe that we have to put this ciphersuite into the EAP method
 > document.

I think one document makes the most sense.

--
t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy

---

From: Jouni Malinen <[email-masked]>
Date: Sun, 16 Jul 2006 10:22:29 -0700

>   Personally I'm somewhat disappointed that AES-EAX was chosen, even though it's fame is that is simpler than CCM, which is what 802.11i proposes. Not having participated in the discussions on algo…

It depends.. So far, I have only needed to implement AES-EAX because of
EAP-PSK and now EAP-GPSK, i.e., I haven't needed it for anything else in
IEEE 802.11/802.1X/EAP area. I did need to implement CCM for IEEE
802.11i. However, it is used only for data frame encryption/decryption
(IEEE 802.11i uses AES key wrap algorithm, RFC 3394, in higher layer
operations) and in many designs, it is not easily available for the EAP
implementation. CCMP (AES-CCM) may be implemented in the hardware/
firmware/device driver and there may not be an interface for the EAP
server/peer (usually, a user space application) to access the same
implementation. Sure, it is possible to re-use the same code, but that
may not be the most common solution. In addition, adding another mode of
AES in software is not really taking that much space.

In other words, I'm not too concerned from the view point of
implementation size of EAX vs. CCM. However, I would have to admit that
it would have been easier to implement EAP-PSK (and now GPSK) if CCM
had been used instead of EAX since I first had to figure out what
exactly EAX is doing whereas I was already familiar with CCM because of
IEEE 802.11i background.

-- 
Jouni Malinen                                            PGP id EFC895FA