From emu-bounces@ietf.org Sat Jul 08 01:51:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz5ia-0002z6-AC; Sat, 08 Jul 2006 01:51:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz5iZ-0002z0-0K for emu@ietf.org; Sat, 08 Jul 2006 01:51:03 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fz5iW-0007VY-IC for emu@ietf.org; Sat, 08 Jul 2006 01:51:02 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k685oxLO019232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 7 Jul 2006 22:50:59 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k685owl1005812; Fri, 7 Jul 2006 22:50:58 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Jul 2006 22:50:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Jul 2006 22:50:58 -0700 Message-ID: In-Reply-To: <7210B31550AC934A8637D6619739CE6906E493A9@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-simon-emu-rfc2716bis-02 Thread-Index: AcZh2TkZi5F5kdq9TUaIvqxDmo/VMxAcixTw From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 08 Jul 2006 05:50:58.0704 (UTC) FILETIME=[7C897900:01C6A252] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Bernard Aboba Subject: [Emu] Review of draft-simon-emu-rfc2716bis-02 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org All, Apologies for such a long delay - this review is long overdue (since I volunteered to review 01 after Dallas)!=20 The draft is mostly in good shape. I have the following comments/questions on it (I'm trying not to cover the ones that Joe's comments have already addressed or those that are already under discussion).=20 Technical Comments:=20 1. Parts of the draft seem to be written with PPP as the EAP lower layer in mind (e.g., Fragmentation and certificate revocation text) - given that EAP is widely used over other lower layers now, there should probably be some text to support that.=20 2. Section 2 refers to client authentication via means other than certificates. While client authentication is optional in TLS, when present, isn't it always based on certs? I haven't fully read 4346bis - perhaps something has changed there. Other TLS-based protocols will be different EAP methods (and hence, different EAP Types) anyway, right? So, I'm confused by the text on other peer authentication means.=20 3. Towards the end of section 2.1, the following text is present "The peer will then verify the hash in order to authenticate the EAP server." A hash cannot be sufficient to authenticate the server. I think the "verify_data" in the TLS finished message is a PRF - so, I'd imagine this to be an HMAC? I'd think that either an HMAC or a signature is required to authenticate the server.=20 4. In section 2.1, the following text on server authentication failure is present:=20 "To ensure that the EAP Server receives the TLS alert message, the peer MUST wait for the EAP-Server to reply before terminating the conversation. The EAP Server MUST reply with an EAP-Failure packet since server authentication failure is a terminal condition." If the server authentication fails, I am not sure how the server can be trusted to send an EAP-Failure packet. So, this requirement is confusing to me.=20 5. Some of the text on identity verification in section 2.4 may actually belong in the security considerations section. For e.g., I'm not sure what it means to say that a peer "MUST" verify the validity of the server certificate - this is not an observable on-the-wire behavior and hence, does not affect protocol interoperability or compliance. The goal is to ensure good security practice by verifying the validity - it may make more sense to talk about this in security considerations, rather than make this a requirement on the protocol.=20 6. Section 2.5 shows the MSK split (0-31 and 32-63) and explains the usage as in RFC2548. As written, it gives the impression that the halves are always used as described in the text (i.e., RECV and SEND encryption keys). Since this is not always true (for e.g., no part of the MSK is directly used for encryption in 802.11i), it would be good to have a statement about that.=20 7. Section 4.6 talks about modifiying the EAP-TLS Type field, thereby causing a downgrade attack by forcing a different TLS-based EAP method. I'm not sure why this needs to particularly be another "TLS-based" EAP method. Isn't the attack on the EAP Type field (that indicates the packet is EAP-TLS), in which case, the downgrade could potentially be to any other EAP method (not just TLS-based)?=20 Editorial Comments:=20 8. Section 2 is titled "Protocol Overview" and section 3 is titled "Detailed Description of the EAP TLS Protocol" - however, section 3 only covers the message formats. It looks like Section 2 is the only protocol description that is available. It would be good to name these sections appropriately.=20 9. A section on differences from RFC2716 would be useful.=20 Regards, Vidya _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Jul 11 09:24:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0IEU-0006JU-Jn; Tue, 11 Jul 2006 09:24:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0IES-0006Ij-Pa for emu@ietf.org; Tue, 11 Jul 2006 09:24:56 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0IER-00060S-GN for emu@ietf.org; Tue, 11 Jul 2006 09:24:56 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 11 Jul 2006 06:24:55 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k6BDOtBM009364; Tue, 11 Jul 2006 06:24:55 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6BDOrDF014658; Tue, 11 Jul 2006 06:24:54 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jul 2006 06:24:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Jul 2006 06:24:51 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Presentations for EMU Thread-Index: Acak7WP1L6erPz25RcW6aZ6BjwF0sQ== From: "Joseph Salowey \(jsalowey\)" To: , "Bernard Aboba" , "Hao Zhou \(hzhou\)" , "Pascal Urien" , "Mitton, Dave" X-OriginalArrivalTime: 11 Jul 2006 13:24:54.0160 (UTC) FILETIME=[655F8100:01C6A4ED] DKIM-Signature: a=rsa-sha1; q=dns; l=203; t=1152624295; x=1153488295; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:Presentations=20for=20EMU; X=v=3Dcisco.com=3B=20h=3DMGIywXxah8pzwYdluW7Wfn2Hvok=3D; b=pHBlcsRa6EgJUJfq0epkGEMSzP0olCKZeeLP0R0pvhSDR+Ist56mPuiSxAcKyCcvFIdWaG01 1gbcI8t4mYu66Dxt/xCwP/CP7vkPu6Od42khfA/qJhteS5xj3go0qGAX; Authentication-Results: sj-dkim-3.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: emu@ietf.org Subject: [Emu] Presentations for EMU X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org The EMU agenda is available here: http://www3.ietf.org/proceedings/06jul/agenda/emu.txt Presenters please send me your presentations sometime today so I can upload them. =20 Thank you, Joe _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Jul 12 09:23:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0egD-0005bz-TB; Wed, 12 Jul 2006 09:23:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0egC-0005bm-Fh for emu@ietf.org; Wed, 12 Jul 2006 09:23:04 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0eg9-0002bH-MZ for emu@ietf.org; Wed, 12 Jul 2006 09:23:04 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6CDN0Kw013863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 12 Jul 2006 06:23:00 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-161.qualcomm.com [10.50.76.161]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6CDMstb028255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 12 Jul 2006 06:22:57 -0700 (PDT) Message-Id: <7.0.1.0.2.20060711072555.043cf6c0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 12 Jul 2006 05:49:48 -0700 To: emu@ietf.org From: Lakshminath Dondeti In-Reply-To: <7.0.1.0.2.20060710002431.04b98588@qualcomm.com> References: <7.0.1.0.2.20060710002431.04b98588@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9b281509fec590bb711c36d4c3ba4f74 Subject: [Emu] Review of draft-clancy-emu-eap-shared-secret-01 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org 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 >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. > >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) > > 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? > > >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) >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) > Received: from [129.46.50.159] by web54402.mail.yahoo.com via HTTP; Wed, 12 Jul 2006 09:50:15 PDT Date: Wed, 12 Jul 2006 09:50:15 -0700 (PDT) From: "M. Vanderveen" Subject: Re: [Emu] Review of draft-clancy-emu-eap-shared-secret-01 To: Lakshminath Dondeti , emu@ietf.org In-Reply-To: <7.0.1.0.2.20060711072555.043cf6c0@qualcomm.com> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1763857645==" Errors-To: emu-bounces@ietf.org --===============1763857645== Content-Type: multipart/alternative; boundary="0-639589936-1152723015=:87703" Content-Transfer-Encoding: 8bit --0-639589936-1152723015=:87703 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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 Lakshminath Dondeti wrote: > > 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. --------------------------------- Do you Yahoo!? Next-gen email? Have it all with the all-new Yahoo! Mail Beta. --0-639589936-1152723015=:87703 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
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

Lakshminath Dondeti <ldondeti@qualcomm.com> wrote:
>
> 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.

Do you Yahoo!?
Next-gen email? Have it all with the all-new Yahoo! Mail Beta. --0-639589936-1152723015=:87703-- --===============1763857645== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============1763857645==-- From emu-bounces@ietf.org Wed Jul 12 13:19:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0iLr-0005wu-5d; Wed, 12 Jul 2006 13:18:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0iLp-0005wP-Fe for emu@ietf.org; Wed, 12 Jul 2006 13:18:17 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0iLG-00076L-Bn for emu@ietf.org; Wed, 12 Jul 2006 13:17:43 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6CHHewL019610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Jul 2006 10:17:41 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-91.qualcomm.com [10.50.76.91]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6CHHajf010265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jul 2006 10:17:39 -0700 (PDT) Message-Id: <7.0.1.0.2.20060712100845.0418ec58@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 12 Jul 2006 10:17:31 -0700 To: "M. Vanderveen" , emu@ietf.org From: Lakshminath Dondeti Subject: Re: [Emu] Review of draft-clancy-emu-eap-shared-secret-01 In-Reply-To: <20060712165015.57845.qmail@web54402.mail.yahoo.com> References: <7.0.1.0.2.20060711072555.043cf6c0@qualcomm.com> <20060712165015.57845.qmail@web54402.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org 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 > >Lakshminath Dondeti wrote: > > > > 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. > > >Do you Yahoo!? >Next-gen email? Have it all with the >all-new >Yahoo! Mail Beta. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Jul 12 13:19:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0iLt-0005zo-Ra; Wed, 12 Jul 2006 13:18:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0iLs-0005zR-L5 for emu@ietf.org; Wed, 12 Jul 2006 13:18:20 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0iJl-00073Q-R8 for emu@ietf.org; Wed, 12 Jul 2006 13:16:11 -0400 Received: (qmail invoked by alias); 12 Jul 2006 17:16:08 -0000 Received: from h01fd-net84db.lab.risq.net (EHLO [132.219.1.253]) [132.219.1.253] by mail.gmx.net (mp040) with SMTP; 12 Jul 2006 19:16:08 +0200 X-Authenticated: #29516787 Message-ID: <44B52E56.6010407@gmx.net> Date: Wed, 12 Jul 2006 13:16:06 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Vanderveen" Subject: Re: [Emu] Review of draft-clancy-emu-eap-shared-secret-01 References: <20060712165015.57845.qmail@web54402.mail.yahoo.com> In-Reply-To: <20060712165015.57845.qmail@web54402.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Michaela, M. Vanderveen wrote: > I agree with Lakshminath regarding the point about having actual > 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. > > 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? 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 /* wrote: > > > > > 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. > > ------------------------------------------------------------------------ > Do you Yahoo!? > Next-gen email? Have it all with the all-new Yahoo! Mail Beta. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Jul 12 13:47:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0inE-0002za-Hr; Wed, 12 Jul 2006 13:46:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0inC-0002zV-VJ for emu@ietf.org; Wed, 12 Jul 2006 13:46:34 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0inB-0001Sj-Gi for emu@ietf.org; Wed, 12 Jul 2006 13:46:34 -0400 Received: (qmail invoked by alias); 12 Jul 2006 17:46:32 -0000 Received: from h01fd-net84db.lab.risq.net (EHLO [132.219.1.253]) [132.219.1.253] by mail.gmx.net (mp031) with SMTP; 12 Jul 2006 19:46:32 +0200 X-Authenticated: #29516787 Message-ID: <44B5357C.5060300@gmx.net> Date: Wed, 12 Jul 2006 13:46:36 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lakshminath Dondeti Subject: Re: [Emu] Review of draft-clancy-emu-eap-shared-secret-01 References: <7.0.1.0.2.20060711072555.043cf6c0@qualcomm.com> <20060712165015.57845.qmail@web54402.mail.yahoo.com> <7.0.1.0.2.20060712100845.0418ec58@qualcomm.com> In-Reply-To: <7.0.1.0.2.20060712100845.0418ec58@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org 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. > > 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 >> >> Lakshminath Dondeti wrote: >> > >> > 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. >> >> >> Do you Yahoo!? >> Next-gen email? Have it all with the >> all-new >> Yahoo! Mail Beta. > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Jul 12 13:57:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0iwS-0008KG-K3; Wed, 12 Jul 2006 13:56:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0iwR-0008K9-3F for emu@ietf.org; Wed, 12 Jul 2006 13:56:07 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0iwP-0002pA-N3 for emu@ietf.org; Wed, 12 Jul 2006 13:56:07 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6CHu0HH022176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Jul 2006 10:56:01 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-91.qualcomm.com [10.50.76.91]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6CHtw5I026678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jul 2006 10:55:59 -0700 (PDT) Message-Id: <7.0.1.0.2.20060712105107.06f86208@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 12 Jul 2006 10:55:56 -0700 To: Hannes Tschofenig From: Lakshminath Dondeti Subject: Re: [Emu] Review of draft-clancy-emu-eap-shared-secret-01 In-Reply-To: <44B5357C.5060300@gmx.net> References: <7.0.1.0.2.20060711072555.043cf6c0@qualcomm.com> <20060712165015.57845.qmail@web54402.mail.yahoo.com> <7.0.1.0.2.20060712100845.0418ec58@qualcomm.com> <44B5357C.5060300@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org At 10:46 AM 7/12/2006, Hannes Tschofenig wrote: >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 >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. >>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 >>> >>>Lakshminath Dondeti wrote: >>> > >>> > 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. >>> >>> >>>Do you Yahoo!? >>>Next-gen email? Have it all with the >>>all-new >>>Yahoo! Mail Beta. >> >>_______________________________________________ >>Emu mailing list >>Emu@ietf.org >>https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Jul 12 14:06:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0j5i-0001IH-BX; Wed, 12 Jul 2006 14:05:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0j5h-0001I8-HN for emu@ietf.org; Wed, 12 Jul 2006 14:05:41 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0j5h-0005kj-2i for emu@ietf.org; Wed, 12 Jul 2006 14:05:41 -0400 Received: (qmail invoked by alias); 12 Jul 2006 18:05:40 -0000 Received: from h01fd-net84db.lab.risq.net (EHLO [132.219.1.253]) [132.219.1.253] by mail.gmx.net (mp038) with SMTP; 12 Jul 2006 20:05:40 +0200 X-Authenticated: #29516787 Message-ID: <44B539F0.6060803@gmx.net> Date: Wed, 12 Jul 2006 14:05:36 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lakshminath Dondeti Subject: Re: [Emu] Review of draft-clancy-emu-eap-shared-secret-01 References: <7.0.1.0.2.20060711072555.043cf6c0@qualcomm.com> <20060712165015.57845.qmail@web54402.mail.yahoo.com> <7.0.1.0.2.20060712100845.0418ec58@qualcomm.com> <44B5357C.5060300@gmx.net> <7.0.1.0.2.20060712105107.06f86208@qualcomm.com> In-Reply-To: <7.0.1.0.2.20060712105107.06f86208@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Lakshminath, Lakshminath Dondeti wrote: > At 10:46 AM 7/12/2006, Hannes Tschofenig wrote: > >> 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. 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. > >> 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. 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 > > Lakshminath > > >> 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. >>> 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 >>>> >>>> Lakshminath Dondeti wrote: >>>> > >>>> > 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. >>>> >>>> >>>> Do you Yahoo!? >>>> Next-gen email? Have it all with the >>>> all-new >>>> Yahoo! Mail Beta. >>> >>> >>> _______________________________________________ >>> Emu mailing list >>> Emu@ietf.org >>> https://www1.ietf.org/mailman/listinfo/emu > > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Jul 13 10:06:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11pL-0006D5-Km; Thu, 13 Jul 2006 10:06:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11pL-0006Cv-7M for emu@ietf.org; Thu, 13 Jul 2006 10:06:03 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G11pJ-0005Tg-Ta for emu@ietf.org; Thu, 13 Jul 2006 10:06:03 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 13 Jul 2006 07:06:01 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DE61I5003782; Thu, 13 Jul 2006 07:06:01 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6DE5uJw001737; Thu, 13 Jul 2006 07:06:01 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jul 2006 07:05:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Jul 2006 07:05:55 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF-66 EMU working group summary Thread-Index: AcamhXV6SrxUuJXTSMGKJdnu2wOCPQ== From: "Joseph Salowey \(jsalowey\)" To: , X-OriginalArrivalTime: 13 Jul 2006 14:05:57.0637 (UTC) FILETIME=[768BC350:01C6A685] DKIM-Signature: a=rsa-sha1; q=dns; l=1787; t=1152799561; x=1153663561; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:IETF-66=20EMU=20working=20group=20summary; X=v=3Dcisco.com=3B=20h=3DFAi8v2HQU2d91ZVfx1ZOVBA4b0U=3D; b=j6/nZBBRqIKCMIYfCpNgE6bMG2nzgjw9C3KqPpcwDshvxoDNlFtEueiiF+dDhklOuE7Q8BHj u48bhTTGaxjUeZB+FfY++rkGMNEBHCOdutMiYgTD99GdyCAszMD76Agb; Authentication-Results: sj-dkim-3.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: hartmans-ietf@mit.edu, Russ Housley Subject: [Emu] IETF-66 EMU working group summary X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org The EMU working group meet at 9AM on Wednesday The first topic of discussion was presented by Hannes Tschofenig on the draft Generalized Pre-shared key (GPSK) EAP method which specifies a PSK EAP Method. There was consensus in the room to take this on as a working group item to meet the PSK charter item with a modification to the defined cipersuites (switch AES-CCM for AES-EAX). The action is to solicit comments on if this should be accepted as a working group item on the EMU list.=20 Next Bernard Aboba discussed the RFC2716bis (EAP-TLS) document. The presentation discussed some open issues of the draft. Interoperability problems with the TLS 3DES ciphersuites were discussed. It was noted that some variants of EAP methods based on TLS method used the same label strings in deriving the MSK from the TLS master secret. This is thought to lead to some potential problems so it might be advisable to use different label strings for this in the future. Lastly, identity privacy using TLS was discussed. The draft needs to be updated and listed as a working group draft on the charter page. Next we had some presentations on EAP-TLS related methods. Hannes Tschofenig presented on EAP-TLS-PSK which is an EAP method specifically for TLS PSK ciphersuites. Pascal Urien presented on an identity privacy scheme for TLS. The general feeling was this would be better evaluated by the TLS group. Hao Zhou presented on some possible enhancements for EAP-TLS. More discussion on enhanced EAP-TLS is needed on the list.=20 Dave Mitton presented on issues implementing new EAP methods. One problem was that some access points don't pass some EAP types they don't know about. The action is to assist the WIFI alliance develop tests for this. =20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Jul 15 18:29:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1sdY-0001BC-G2; Sat, 15 Jul 2006 18:29:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1sdX-0001B7-Ip for emu@ietf.org; Sat, 15 Jul 2006 18:29:23 -0400 Received: from dispatch.cs.umd.edu ([128.8.128.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1sdW-0003uN-BT for emu@ietf.org; Sat, 15 Jul 2006 18:29:23 -0400 Received: from delegate.pc.cs.umd.edu (exchange.cs.umd.edu [128.8.130.248]) by dispatch.cs.umd.edu (8.12.11.20060308/8.12.5) with ESMTP id k6FMT4Io000466; Sat, 15 Jul 2006 18:29:08 -0400 Received: from [192.168.0.101] ([71.123.36.170]) by delegate.pc.cs.umd.edu with Microsoft SMTPSVC(6.0.3790.1830); Sat, 15 Jul 2006 18:29:02 -0400 Message-ID: <44B96C70.3030800@cs.umd.edu> Date: Sat, 15 Jul 2006 18:30:08 -0400 From: Charles Clancy User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Emu] Review of draft-clancy-emu-eap-shared-secret-01 References: <7.0.1.0.2.20060711072555.043cf6c0@qualcomm.com> <20060712165015.57845.qmail@web54402.mail.yahoo.com> <7.0.1.0.2.20060712100845.0418ec58@qualcomm.com> <44B5357C.5060300@gmx.net> <7.0.1.0.2.20060712105107.06f86208@qualcomm.com> <44B539F0.6060803@gmx.net> In-Reply-To: <44B539F0.6060803@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jul 2006 22:29:02.0193 (UTC) FILETIME=[12C4FE10:01C6A85E] X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more information X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (score=0.374, required 5, autolearn=disabled, DNS_FROM_RFC_ABUSE 0.37) X-MailScanner-From: clancy@cs.umd.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >> So I am drawing from the experience of IKEv2 and ESPv3. The idea is >> 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. | tcc@umd.edu | www.cs.umd.edu/~clancy _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Jul 16 13:23:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2ALR-0003EW-JW; Sun, 16 Jul 2006 13:23:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2ALQ-0003ER-4d for emu@ietf.org; Sun, 16 Jul 2006 13:23:52 -0400 Received: from mail2.genealogia.fi ([194.100.116.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2ALN-0001CY-Ld for emu@ietf.org; Sun, 16 Jul 2006 13:23:52 -0400 Received: from dsl017-049-110.sfo4.dsl.speakeasy.net ([69.17.49.110] helo=jm) by mail2.genealogia.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1G2AKo-000753-Tx; Sun, 16 Jul 2006 20:23:16 +0300 Received: by jm (sSMTP sendmail emulation); Sun, 16 Jul 2006 10:22:29 -0700 Date: Sun, 16 Jul 2006 10:22:29 -0700 From: Jouni Malinen To: "M. Vanderveen" Subject: Re: [Emu] Review of draft-clancy-emu-eap-shared-secret-01 Message-ID: <20060716172229.GE18824@jm.kir.nu> References: <7.0.1.0.2.20060711072555.043cf6c0@qualcomm.com> <20060712165015.57845.qmail@web54402.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060712165015.57845.qmail@web54402.mail.yahoo.com> User-Agent: Mutt/1.5.11 X-Spam-Score: -2.6 (--) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Wed, Jul 12, 2006 at 09:50:15AM -0700, M. Vanderveen wrote: > 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? 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 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Jul 16 19:33:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2G7B-0001ij-T6; Sun, 16 Jul 2006 19:33:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2G7A-0001ie-LX for emu@ietf.org; Sun, 16 Jul 2006 19:33:32 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2G79-0006V2-B7 for emu@ietf.org; Sun, 16 Jul 2006 19:33:32 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6GNXTm3028689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 16 Jul 2006 16:33:30 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-72-202.qualcomm.com [10.50.72.202]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6GNXShn029302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 16 Jul 2006 16:33:29 -0700 (PDT) Message-Id: <7.0.1.0.2.20060716151635.0681e870@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 16 Jul 2006 16:33:26 -0700 To: emu@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Emu] CCM vs. EAX, and the specification of combined mode use in GPSK X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I've finally had a chance to take a quick look at the relative differences between CCM and EAX. From the EAX paper, it appears that the differences are in efficiency: simplicity of nonce construction, possibility for pre-computation of auth data on fixed headers and finally the online property of EAX seem to be the advantages over CCM. I am curious about others' opinions on EAX vs. CCM. Both of these modes seem to re-use a key for encryption and integrity protection. My recollection is that the same key is used in both directions. That could be a problem with counter mode if the IV construction is not done right. 802.11i, IPsec and 802.16e's constructions of the IV are different. We need to make sure that is fully specified in the current document. Thoughts? regards, Lakshminath _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Jul 16 19:34:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2G7c-0001ka-1k; Sun, 16 Jul 2006 19:34:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2G7a-0001kU-GA for emu@ietf.org; Sun, 16 Jul 2006 19:33:58 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2G7X-0006bf-4r for emu@ietf.org; Sun, 16 Jul 2006 19:33:58 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6GNXfkM002956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 16 Jul 2006 16:33:41 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-72-202.qualcomm.com [10.50.72.202]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6GNXdRs016766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 16 Jul 2006 16:33:40 -0700 (PDT) Message-Id: <7.0.1.0.2.20060716150131.0703b6a8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 16 Jul 2006 15:12:10 -0700 To: Hannes Tschofenig , Charles Clancy From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: emu@ietf.org Subject: [Emu] My review of GPSK X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi, My review has a number of nits and issues, big and small. We have a thread going on whether to separate the algorithms part into a different document or not. I will try and post the major issues in separate threads. thanks. Lakshminath _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Jul 16 19:35:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2G9V-0001sO-Q5; Sun, 16 Jul 2006 19:35:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2G9V-0001sJ-HL for emu@ietf.org; Sun, 16 Jul 2006 19:35:57 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2G9U-0006s8-68 for emu@ietf.org; Sun, 16 Jul 2006 19:35:57 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6GNZstX003145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 16 Jul 2006 16:35:55 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-72-202.qualcomm.com [10.50.72.202]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6GNZrUk025672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 16 Jul 2006 16:35:54 -0700 (PDT) Message-Id: <7.0.1.0.2.20060716163329.03f3dcd0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 16 Jul 2006 16:35:52 -0700 To: emu@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Emu] Duplicate integrity protection on Protected Payload data in GPSK X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org My reading of the GPSK draft is that the Protected Payload data will be integrity protected using the MAC from the combined mode and there is the integrity checksum over the entire GPSK-Message. I think we should avoid the multiple MACs. Thoughts? regards, Lakshminath _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Jul 16 20:49:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2HIx-0000qE-Uz; Sun, 16 Jul 2006 20:49:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2HIw-0000q6-14 for emu@ietf.org; Sun, 16 Jul 2006 20:49:46 -0400 Received: from rwcrmhc15.comcast.net ([204.127.192.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2HIt-0001LH-P2 for emu@ietf.org; Sun, 16 Jul 2006 20:49:46 -0400 Received: from [192.168.0.2] (c-68-49-199-146.hsd1.md.comcast.net[68.49.199.146]) by comcast.net (rwcrmhc15) with ESMTP id <20060717004942m1500n58r2e>; Mon, 17 Jul 2006 00:49:42 +0000 Message-ID: <44BADF23.4020700@cs.umd.edu> Date: Sun, 16 Jul 2006 20:51:47 -0400 From: Charles Clancy User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lakshminath Dondeti Subject: Re: [Emu] Duplicate integrity protection on Protected Payload data in GPSK References: <7.0.1.0.2.20060716163329.03f3dcd0@qualcomm.com> In-Reply-To: <7.0.1.0.2.20060716163329.03f3dcd0@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org > My reading of the GPSK draft is that the Protected Payload data will > be integrity protected using the MAC from the combined mode and there > is the integrity checksum over the entire GPSK-Message. I think we > should avoid the multiple MACs. ... > I am curious about others' opinions on EAX vs. CCM. We could replace AES-EAX with AES-CBC. Would address both your concerns? -- t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Jul 17 02:42:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2MoF-0001Dp-SX; Mon, 17 Jul 2006 02:42:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2MoE-0001Dk-3z for emu@ietf.org; Mon, 17 Jul 2006 02:42:26 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2MoC-00020Y-PN for emu@ietf.org; Mon, 17 Jul 2006 02:42:26 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6H6gGPR015977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 16 Jul 2006 23:42:17 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-77-125.qualcomm.com [10.50.77.125]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6H6gFKE021100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 16 Jul 2006 23:42:16 -0700 (PDT) Message-Id: <7.0.1.0.2.20060716232838.0716eec0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 16 Jul 2006 23:42:19 -0700 To: Charles Clancy From: Lakshminath Dondeti Subject: Re: [Emu] Duplicate integrity protection on Protected Payload data in GPSK In-Reply-To: <44BADF23.4020700@cs.umd.edu> References: <7.0.1.0.2.20060716163329.03f3dcd0@qualcomm.com> <44BADF23.4020700@cs.umd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org At 05:51 PM 7/16/2006, Charles Clancy wrote: > > My reading of the GPSK draft is that the Protected Payload data will > > be integrity protected using the MAC from the combined mode and there > > is the integrity checksum over the entire GPSK-Message. I think we > > should avoid the multiple MACs. > >... > > > I am curious about others' opinions on EAX vs. CCM. > >We could replace AES-EAX with AES-CBC. Would address both your concerns? That's one way, sure! Given that the encryption might be over only one of the payloads of the GPSK messages and since these are key management messages anyway (just 4 messages, at initial authentication), we don't need the processing efficiencies of CTR mode that comes with EAX or CCM. So AES-CBC is just fine. If we do want to use EAX or CCM, a possibility is to "apply" EAX or CCM over the entire message with most of the message as the AAD and have the encryption spanning either the Protected Payload data or NULL. (My recollection is that Joe and I discussed this in Montreal as a possibility; not sure whether we agreed on it though!) regards, Lakshminath >-- >t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Jul 17 07:09:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Qyj-0007Ow-6p; Mon, 17 Jul 2006 07:09:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Qyh-0007Or-T1 for emu@ietf.org; Mon, 17 Jul 2006 07:09:31 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G2Q9l-0007aR-JZ for emu@ietf.org; Mon, 17 Jul 2006 06:16:56 -0400 Received: (qmail invoked by alias); 17 Jul 2006 10:16:51 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp028) with SMTP; 17 Jul 2006 12:16:51 +0200 X-Authenticated: #29516787 Message-ID: <44BB638E.3090404@gmx.net> Date: Mon, 17 Jul 2006 12:16:46 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lakshminath Dondeti Subject: Re: [Emu] Duplicate integrity protection on Protected Payload data in GPSK References: <7.0.1.0.2.20060716163329.03f3dcd0@qualcomm.com> In-Reply-To: <7.0.1.0.2.20060716163329.03f3dcd0@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Lakshminath, this would make the design more difficult. There is almost no performance penality of having two MACs. Ciao Hannes Lakshminath Dondeti wrote: > My reading of the GPSK draft is that the Protected Payload data will be > integrity protected using the MAC from the combined mode and there is > the integrity checksum over the entire GPSK-Message. I think we should > avoid the multiple MACs. > > Thoughts? > > regards, > Lakshminath > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Jul 17 23:41:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2gSp-0001LG-9s; Mon, 17 Jul 2006 23:41:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2gSn-0001LB-KY for emu@ietf.org; Mon, 17 Jul 2006 23:41:37 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2gSm-00066E-8W for emu@ietf.org; Mon, 17 Jul 2006 23:41:37 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6I3fWhQ021893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 17 Jul 2006 20:41:32 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-68-212.qualcomm.com [10.50.68.212]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6I3fUQF005373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 17 Jul 2006 20:41:31 -0700 (PDT) Message-Id: <7.0.1.0.2.20060717203208.045a4160@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 17 Jul 2006 20:41:29 -0700 To: Hannes Tschofenig From: Lakshminath Dondeti Subject: Re: [Emu] Duplicate integrity protection on Protected Payload data in GPSK In-Reply-To: <44BB638E.3090404@gmx.net> References: <7.0.1.0.2.20060716163329.03f3dcd0@qualcomm.com> <44BB638E.3090404@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org At 03:16 AM 7/17/2006, Hannes Tschofenig wrote: >Hi Lakshminath, > >this would make the design more difficult. > >There is almost no performance penality of having two MACs. I disagree in this case. Unless there is a strong need to have separate MAC protection for the Protected data payload, I think the second MAC is spurious and comes only as a side effect of the use of a combined mode algorithm. Surely that's not a justification for adding 96 or so bits to the GPSK messages. Lakshminath >Ciao >Hannes > >Lakshminath Dondeti wrote: >>My reading of the GPSK draft is that the Protected Payload data >>will be integrity protected using the MAC from the combined mode >>and there is the integrity checksum over the entire >>GPSK-Message. I think we should avoid the multiple MACs. >>Thoughts? >>regards, >>Lakshminath >> >>_______________________________________________ >>Emu mailing list >>Emu@ietf.org >>https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Jul 20 14:36:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3dNU-0007C4-2D; Thu, 20 Jul 2006 14:36:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3dNS-0007Bz-M5 for emu@ietf.org; Thu, 20 Jul 2006 14:36:02 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3dNP-0004qG-Tj for emu@ietf.org; Thu, 20 Jul 2006 14:36:02 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2006 11:35:59 -0700 X-IronPort-AV: i="4.07,163,1151910000"; d="scan'208"; a="306990984:sNHT43093284" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6KIZxNK024927 for ; Thu, 20 Jul 2006 11:35:59 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6KIZx79018771 for ; Thu, 20 Jul 2006 11:35:59 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 11:35:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Jul 2006 11:35:01 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft minutes for EMU meeting - IETF 66 Thread-Index: AcasKzW7ut2QxzflTd63o8kbiyBdOg== From: "Joseph Salowey \(jsalowey\)" Cc: X-OriginalArrivalTime: 20 Jul 2006 18:35:58.0875 (UTC) FILETIME=[5820BEB0:01C6AC2B] DKIM-Signature: a=rsa-sha1; q=dns; l=11326; t=1153420559; x=1154284559; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:Draft=20minutes=20for=20EMU=20meeting=20-=20IETF=2066; X=v=3Dcisco.com=3B=20h=3DlgziJqfReMVRA/bMYMxrofM5czE=3D; b=CPpGXZFwDqYr56F2sRFb9PfIJ1kaHnzB4/vJrN8oHoXA2uig06yVILJijOXV3CEv0Yj0CrCm GCLODciq+VNBx1Nyctjz1vL6ZMNb6uByvf/g9WQhWZhYWSylqZXq6xPx; Authentication-Results: sj-dkim-5.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Subject: [Emu] Draft minutes for EMU meeting - IETF 66 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Here are the draft minutes for the EMU session, let me know if you have any corrections: Minutes for EAP Method Update (EMU) at IETF 66 --------------------------------------------- Date: 7/12/2006 Time: 9 - 11:30 AM Place: Montreal, QC=20 Note takers: Nancy Cam-Winget, Madjid Nakhjiri Summary --------------------------------------------- The first topic of discussion was presented by Hannes Tschofenig on the draft Generalized Pre-shared key (GPSK) EAP method which specifies a PSK EAP Method. There was consensus in the room to take this on as a working group item to meet the PSK charter item with a modification to the defined cipersuites (switch AES-CCM for AES-EAX). The action is to solicit comments on if this should be accepted as a working group item on the EMU list.=20 Next Bernard Aboba discussed the RFC2716bis (EAP-TLS) document. The presentation discussed some open issues of the draft. Interoperability problems with the TLS 3DES ciphersuites were discussed. It was noted that some variants of EAP methods based on TLS method used the same label strings in deriving the MSK from the TLS master secret. This is thought to lead to some potential problems so it might be advisable to use different label strings for this in the future. Lastly, identity privacy using TLS was discussed. The draft needs to be updated and listed as a working group draft on the charter page. Next we had some presentations on EAP-TLS related methods. Hannes Tschofenig presented on EAP-TLS-PSK which is an EAP method specifically for TLS PSK ciphersuites. Pascal Urien presented on an identity privacy scheme for TLS. The general feeling was this would be better evaluated by the TLS group. Hao Zhou presented on some possible enhancements for EAP-TLS. More discussion on enhanced EAP-TLS is needed on the list.=20 Dave Mitton presented on issues implementing new EAP methods. One problem was that some access points don't pass some EAP types they don't know about. The action is to assist the WIFI alliance develop tests for this. =20 Detailed Minutes ----------------------------------------------- 1. Generalized Pre-Shared Key Method (GPSK) - Hannes Tschofenig Hannes Presented Slides Discussion - Key confirmation Russ Housley: wants to make sure that last message has confirmation on last message that both parties have derived the same key Hannes: Message 4 is optional and the encrypted part is also optional Uri Blumenthal: questions need for explicit confirmation since Message 2 and Message 3 provides the information Bernard Aboba: may be confused, in 2nd message should know what the enc and MAC keys are used. The SEC_SK message is authenticated using a new key? Hannes: Confusion was around notation, the MAC's in the messages are using the SK which is derived from the nonces and the PSK. - identity protection Bernard: asks on how identity protection may be achieved?=20 Hannes: Out of scope one approach may be to use only the key identifier Joe Salowey: temporary ID may be used, encrypted payload can deliver it. - ciphersuites Russ: asked why not choosing NIST approved modes? Consider changing it to AES-CCM. David McGrew: recommended use AES-CCM Sam Hartman: questions why have a NULL? Uri: mentioned simplicity thus a reduction, mode was chosen to ensure AES was used and most efficient thus why EAX was chosen. Pasi Eronen: why can it not be replaced with CBC, other people gave other options Joe: mentions crypto selection should not be contentious + Needs discussion on the list and with the ADs.=20 - key hierarchy Hannes: Jouni has already made first cut an implementation of this method. Only took 8 hours. =20 Joe: How many people have read the document? Hands -- 4 - 5 Joe: Hum for "is this in the right direction?" for: lots against: none Joe: Hum to accept as a working group item for: lots against: none + take it to the list 2. RFC 2716bis - Bernard Aboba Bernard presents - Key derivation Bernard: Not a good idea to derive keys using the same label, though this may not be as easy as it seems. Sam: mentions that TLS community should make it easy to change labels for key derivation - Multiple layers of negotiation Sam: does multiple layers of negotiation with EAP-TLS introduce a vulnerability? Bernard: 3748 with respect to protect against downgrade attack, you could NACK it if it is something you don't want to do. - Ciphersuite support Bernard: mandatory to implement ciphersuites: 3DES/HMAC-SHA1 failed interop tests. Some very popular EAP-TLS implementations with 3DES failed to even complete. Possibly results from some changes in openssl. Russ: how about the old openssl? Bernard: not tested Bernard: does anybody has AES implementations we can use and test? + question the list about AES support - Privacy Bernard: what does it mean to be backward compatibility especially with respect to privacy? Bernard's interpretation is that client requiring privacy must fail with server w/no privacy but must connect if it's not configured for privacy with a server with or without privacy.=20 Russ: questions how documentation will clarify these transitions; wants to make sure it's captured.=20 Bernard: responds that all this will be captured in the i-d. Vidya Narayanan: why its an issue with EAP-TLS vs. just TLS.=20 Bernard: responds that it's heightened at least in this group.=20 Hao Zhou: asks whether privacy updates will be mandatory or optional?=20 Bernard: states it'll be made optional Bernard: I will send out a survey for the implementations (so far 4 responses) and work with interop. 3. Enhanced TLS - various presentations =20 *EAP-TLS-PSK - Hannes Tschofenig presents on EAP-TLS-PSK - privacy Bernard: is it possible to support privacy in it. Hannes: I have seen some papers on it that does it without too much work Pasi: you could do within the first handshake, but it is probably a hack.. Hannes: it was not initially a requirement, now it depends who you talk to. - method number and negotiation Question: why is there a mapping of a specific EAP method to negotiate this versus doing it inside EAP-TLS itself?=20 Hannes: responds that they should be equivalent. Sam: comments that options may cause problems when for example, if preference is to do EAP-TLS with some cipher suites vs. EAP-AKA but that fails then it may be better to do it through the EAP-TLS to choose a different ciphersuite then you get into a situation you need to decide which method you are committing before you start the method. EAP does not have a good way of saying this is the method I want to use or half way through it thinks I have a problem with this and want to start another one. Hannes: Isn't this a problem with any general EAP method. Hao: comments that EAP Identity response may include the realm shouldn't that help?=20 Hannes: no, unless credentials are shared. RFC 4284 is there to provide identity selection hint from the server to help;=20 Bernard: comments that while it may hint the network connecting to, but it doesn't really relate to the EAP method so not sure how it helps. John Vollbrecht: mentions that this is important work, but its not clear how we can best proceed forward. *EAP-TLS identity protection - Pascal Urien presents Joe: it seems to be a change in TLS, what would the TLS WG think about this? Sam: post this to TLS as an extension to TLS, and if they are ok, bring back Pasi: as an individual this seems that it would the same end result as adding a couple of roundtrips *EAP-TLS enhancements - Hao Zhou Presents Bernard: comments that this is more like the kitchen sink. Some of the requirements seem viable, but putting them all under one identifier is not good.=20 Joe: agrees but questions that perhaps there is merit to considering trying to put them as one base for several methods.=20 Bernard: responds that having too many options may break interoperability; mixing Kerberos, PSK seem to put things over the top.=20 John: mentions that we should consider this, though its not clear that we could put this into a single standard...but states that this would be a very good thing and mentions that NEA group would need something like this.=20 Joe: mentions that NEA is out of scope for this group.=20 Stefan Santesson: using protected TLS tunnel is a very useful thing. Joe: comments that since TLS is evolving; 2716bis is only a subset and since the presentations today of how to make use of the extensions, it seems that this work is within the scope of this group. There could be one base framework and potentially manifest itself in multiple methods, but we must consider support for the requirements within the group. Joe: Asks whether other people would be willing to edit on the TLS enhancements?=20 3.5 folks=20 Joe: review? 6.5 folks Password based mechanism discussion Joe: What about weak password mechanisms? Are there other alternative to methods like TTLS, PEAP or EAP-FAST? Sam: mentions that tunneled methods is out of scope for our charter, but addressing weak passwords may be within the scope of our charter. Bernard: asks how we're going to deal with PSK, is GPSK it or EAP-TLS-PSK should be considered?=20 Joe: states that GPSK should be it.=20 Sam: it seemed that there was no consensus to consider EAP-TLS-PSK, but it has not been decided yet.=20 Hannes: mentioned that there was enough interest to trigger the design group to generate the GPSK method draft; also mentions the focus of the preso is on passwords not PSK.=20 Stefan: questions the limits of the enhancements, better to include all of the TLS enhancements.=20 Joe: agrees that the intent is to make the interface allow for supporting the new TLS enhancements.=20 Bernard: questions having multiple standards for PSK.=20 Sam: mentions difference between group's adoption of using something that may be widely adopted in our own GPSK versus defining or constraining the ability to use all of the TLS options just because they also support PSK. + Joe concludes: since there's enough interest, we should continue the discussion in the list to see where it leads. 4. Implementation experience - David Mitton David presents Bernard: we had an EAP bakeoff long time ago, maybe we need to have another Bakeoff. Russ: why would the vendors have to come to bakeoff if it is not a new EAP method? Sam: you can figure out characteristics of the problems people are running into and design test case accordingly to have people come and test it ?: In Korea some people have deliberately only allowed specific EAP methods Pasi: there is already procedure where all WiFi vendor come to (alliance), so maybe you can include that right there. Dorothy Stanley: that is a great idea, we can take that idea to WiFi alliance. vendors do their best, nobody is perfect, also iEEE does not do these kinds of tests, WiFi is the best places. Bernard: I have a lot of weirdo problems that maybe RADIUS related not EAP. Joe: it is within our interest that methods that this group develops will be tested. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Jul 20 14:39:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3dQO-0000VO-PT; Thu, 20 Jul 2006 14:39:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3dQN-0000VI-Bo for emu@ietf.org; Thu, 20 Jul 2006 14:39:03 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3dQM-0005Je-2v for emu@ietf.org; Thu, 20 Jul 2006 14:39:03 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 20 Jul 2006 11:39:01 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6KId1DG015784 for ; Thu, 20 Jul 2006 11:39:01 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6KId12D024449 for ; Thu, 20 Jul 2006 11:39:01 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Jul 2006 11:39:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Jul 2006 11:38:01 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GPSK as a working group item Thread-Index: AcasK6FHW7ZvdP/eTgmdm/cfw3GPqw== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 20 Jul 2006 18:39:01.0411 (UTC) FILETIME=[C4ED8730:01C6AC2B] DKIM-Signature: a=rsa-sha1; q=dns; l=234; t=1153420741; x=1154284741; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:GPSK=20as=20a=20working=20group=20item; X=v=3Dcisco.com=3B=20h=3DiYzbSRonbSrWtCzAVhZgNDJ4VXw=3D; b=jytGeXGxem5yTu3h6EOV/R9mZROXfguTvkOBYQfZdXf1/3CfGewgUmPAG+frDHnkFKlP6JQf nQUH+CWs3jQ90QcdUU0G88p5GnE5+zo+eS4Glr/cM4r8gZAiotHd/HT4; Authentication-Results: sj-dkim-3.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Emu] GPSK as a working group item X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org At IETF 66 EMU working group meeting there was consensus to take on draft-clancy-emu-eap-shared-secret-01.txt as a working group item. =20 Are there any objections to taking this on as a working group item? Thanks, Joe=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Jul 20 14:56:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3dhh-0004K3-1r; Thu, 20 Jul 2006 14:56:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3dhf-0004JY-7W for emu@ietf.org; Thu, 20 Jul 2006 14:56:55 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3dY2-0007k3-Uy for emu@ietf.org; Thu, 20 Jul 2006 14:47:01 -0400 Received: by ug-out-1314.google.com with SMTP id m2so976668uge for ; Thu, 20 Jul 2006 11:46:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aFSwDU2GJTVBMUwtxsT1GaQGhe6OSvIXVWIHeaR1hmEak1Q24Y0Spw+E30xmlfOwnZQ76AtuPKPg6IfwEFw6+unOqvBJ8gQAP+0kpoo+Sp1vSylg8g9cU5rdKrvu1d+VDwNhvov7xIrs7y78SJwEDyrUw+TSvtOAzF+WWMvpFkk= Received: by 10.82.109.13 with SMTP id h13mr18628buc; Thu, 20 Jul 2006 11:46:56 -0700 (PDT) Received: by 10.82.109.18 with HTTP; Thu, 20 Jul 2006 11:46:56 -0700 (PDT) Message-ID: Date: Thu, 20 Jul 2006 11:46:56 -0700 From: "Clint Chaplin" To: "Joseph Salowey (jsalowey)" Subject: Re: [Emu] GPSK as a working group item In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 1.9 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org No objection here, since EAP-PAX has been replaced. On 7/20/06, Joseph Salowey (jsalowey) wrote: > At IETF 66 EMU working group meeting there was consensus to take on > draft-clancy-emu-eap-shared-secret-01.txt as a working group item. > > Are there any objections to taking this on as a working group item? > > Thanks, > > Joe > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > -- Clint (JOATMON) Chaplin Wireless Security Technologist Wireless Standards Manager _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Jul 21 12:42:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3y4x-000369-Om; Fri, 21 Jul 2006 12:42:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3y4w-000364-90 for emu@ietf.org; Fri, 21 Jul 2006 12:42:18 -0400 Received: from bay0-omc1-s12.bay0.hotmail.com ([65.54.246.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3y4t-0004tJ-V1 for emu@ietf.org; Fri, 21 Jul 2006 12:42:18 -0400 Received: from hotmail.com ([65.54.161.28]) by bay0-omc1-s12.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 09:42:15 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 21 Jul 2006 09:42:15 -0700 Message-ID: Received: from 65.54.161.200 by by106fd.bay106.hotmail.msn.com with HTTP; Fri, 21 Jul 2006 16:42:12 GMT X-Originating-IP: [131.107.0.72] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: emu@ietf.org Bcc: Subject: Re: [Emu] GPSK as a working group item Date: Fri, 21 Jul 2006 09:42:12 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 21 Jul 2006 16:42:15.0095 (UTC) FILETIME=[9F404C70:01C6ACE4] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org No objection. >On 7/20/06, Joseph Salowey (jsalowey) wrote: >>At IETF 66 EMU working group meeting there was consensus to take on >>draft-clancy-emu-eap-shared-secret-01.txt as a working group item. >> >>Are there any objections to taking this on as a working group item? >> >>Thanks, >> >>Joe >> >>_______________________________________________ >>Emu mailing list >>Emu@ietf.org >>https://www1.ietf.org/mailman/listinfo/emu >> > > >-- >Clint (JOATMON) Chaplin >Wireless Security Technologist >Wireless Standards Manager > >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu