Subject: [Emu] EAP-GPSK update

From: Charles Clancy <[email-masked]>
Date: Sun, 11 Mar 2007 23:22:15 -0400

All,

We've put together an update to the GPSK draft to address the last call 
comments.  Below is a list of the identified issues and their solutions. 
  For a variety of issues we recommended no change with a brief 
description.  If more detail is desired, we can certainly discuss them 
further on the list.

You can find the latest version here, pending the I-D editor's release:

http://www.tschofenig.com/svn/draft-clancy-emu-eap-gpsk/draft-ietf-emu-eap-gpsk-04.txt

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

-----------
  TECHNICAL
-----------

Issue: why not use EAP-TLS-PSK instead (narayanan)
Resolution: no change -- WG consensus was to do GPSK

Issue: MAC does not cover the EAP or GPSK header (Dondeti, Narayanan)
Resolution: no change -- protecting the EAP header is pointless, since
             the EAP engine would not be able to validate the MAC.  The
             GPSK header only includes an op-code, which can be
             implicitly checked by validating the MAC on the rest of the
             packet contents.

Issue: use of SHA-1 (Aboba)
Resolution: switched AES ciphersuite to use SHA256

Issue: KDFs do not appear compliant with draft-dange-nistkdf-01 (Aboba)
Resolution: no change, NIST reviewed our KDF, and the current one is
             based specifically on their recommendations

Issue: Why doesn't the MK derviation use the PSK as it's keying input,
        instead of all zeros?  (Dondeti)
Resolution: no change -- The PSK can be of arbitrary length, and
             therefore may not be the correct length to use as the KDF
             input key.

Issue: revert to previous KDF based on MACs (Dondeti, Narayanan)
Resolution: no change -- the KDF changes from MAC to Hash were
             proposed by NIST

Issue: Use of CTR instead of CBC to avoid implementing AES decryption
        code (Dondeti)
Resolution: no change -- we discussed this at length, CTR does its
             own integrity protection, which would be redundant, hence
             the decision to use CBC instead

Issue: dropping nonparsable packets is EAP behavior (Narayanan)
Resolution: changed to talk about parsing EAP-GPSK packets, rather than
             EAP packets

Issue: derive keys individually rather than deriving a big block
        and then split it up (Narayanan)
Resolution: no change -- places fewer restrictions on the KDF, and
             guarantees cryptographic independence

Issue: derivation of PK when not using an encryption Ciphersuite
        (Narayanan)
Resolution: removed PK from hash ciphersuite discussion, added other
             comments indicating it's lack of necessity for
             non-encrypting ciphersuites

-----------
  EDITORIAL
-----------

Issue: citing old drafts (Malinen)
Resolution: moot, as references were removed

Issue: s/needs to instantiated/needs to be instantiated/ (Malinen)
Resolution: text edited

Issue: discussion of other protocols and deficiencies (Aboba)
Resolution: section removed

Issue: quick availability as a design goal (Aboba)
Resolution: text edited

Issue: design goal s/Wide Applicability/Security Model/ (Aboba)
Resolution: text edited

Issue: efficiency design goal, mention round trips (Aboba)
Resolution: text edited

Issue: efficiency design goal, mention Privacy not supported (Aboba)
Resolution: no change -- privacy supported if AES ciphersuite is used

Issue: define peer/server/session-ID (Aboba)
Resolution: defined

Issue: ambiguous definition of KS with respect to hashes (Dondeti)
Resolution: removed ambiguous text

Issue: erronious references to multiple protected payload blocks (Dondeti)
Resolution: fixed some references -- others referred to them as plural
             as you can have a total 3 in the entire protocol exchange

Issue: order of key definitions in terminology section (Dondeti)
Resolution: changed the order to be alphabetical -- not quite what was
             proposed, but logical IMHO

Issue: precision of some of the protocol specification (Dondeti)
Resolution: made some minor edits

Issue: GPSK-4 is needed only as a filler, specify that (Dondeti)
Resolution: no change, GPSK-4 can contain a PD_Payload_Block

Issue: Text involving validation of keys after GPSK-4 (Dondeti)
Resolution: text revised

Issue: discussion of MACs in KDF section (Dondeti)
Resolution: text replaced

Issue: instead of length(Csuites_List) use NumberOf_CSuites to save
        one byte (Dondeti)
Resolution: no change -- using a 2-byte length makes parsing code
             consistent across all length-prefixed data blocks

Issue: EAP terminology renamed (Narayanan)
Resolution: s/client/peer/g

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 11 Mar 2007 20:58:22 -0700

++++++
+++++

Charles,

CTR mode encryption does not include integrity protection.  There are 
what are known as combined modes, e.g., CCM, OCB, GCM, which use CTR 
mode for encryption.  I am not talking about using CCM or something like 
that.

I am proposing using CTR mode alone.

thanks,
Lakshminath

---

From: Charles Clancy <[email-masked]>
Date: Mon, 12 Mar 2007 08:20:54 -0500

> mode for encryption.  I am not talking about using CCM or something like

I have no objection to switching from CBC to CTR.  Anyone else have an 
opinion?

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

---

From: "Clint Chaplin" <[email-masked]>
Date: Mon, 12 Mar 2007 09:47:58 -0700

What does NIST (FIPS) have to say?

-- 
Clint (JOATMON) Chaplin
Principal Engineer
Corporate Standardization (US)
SISA

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Mon, 12 Mar 2007 10:52:48 -0700

We discussed using CBC mode because it was slightly simpler than CTR
mode.  What is the significant advantage you see with CTR mode?  

Joe

> -----Original Message-----
> From: Charles Clancy [mailto:[email-masked]] 
> Sent: Monday, March 12, 2007 6:21 AM
> To: Lakshminath Dondeti
> Cc: [email-masked]
> Subject: [Emu] Re: On my suggestion to use CTR mode instead of CBC
> 
>  > CTR mode encryption does not include integrity protection. 
>  There are  > what are known as combined modes, e.g., CCM, 
> OCB, GCM, which use CTR  > mode for encryption.  I am not 
> talking about using CCM or something like  > that.
> 
> I have no objection to switching from CBC to CTR.  Anyone 
> else have an opinion?
> 
> --

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 12 Mar 2007 10:58:17 -0700

> mode.  What is the significant advantage you see with CTR mode?  

CTR mode as the encryption algorithm and AES_CMAC_128 as the integrity 
algorithm requires the implementation of the forward operation of the 
cipher only.

I missed the part about CBC being simpler (btw, I have nothing against 
CBC :) ).  Could you refresh my memory?  Thanks.

regards,
Lakshminath

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Mon, 12 Mar 2007 11:12:56 -0700

> From: Lakshminath Dondeti [mailto:[email-masked]] 
> Sent: Monday, March 12, 2007 10:58 AM
> To: Joseph Salowey (jsalowey)
> Cc: Charles Clancy; [email-masked]
> Subject: Re: [Emu] Re: On my suggestion to use CTR mode instead of CBC
> 
> CTR mode as the encryption algorithm and AES_CMAC_128 as the 
> integrity algorithm requires the implementation of the 
> forward operation of the cipher only.
> 
[Joe] Would this make the implementation more compact?  

> I missed the part about CBC being simpler (btw, I have 
> nothing against CBC :) ).  Could you refresh my memory?  Thanks.
> 
[Joe] Most implementers are fairly familiar with CBC and its use, many
libraries are available for it.  CTR is a less familiar, which can
result in difficulties in counter management.  

> OCB, GCM, 
> >> which use CTR  > mode for encryption.  I am not talking 
> about using 
> >> CCM or something like  > that.
> >>
> else have 
> >> an opinion?

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 12 Mar 2007 11:18:58 -0700

> [Joe] Would this make the implementation more compact?  

Yep!

> result in difficulties in counter management.  

CTR mode is common enough now :).

Lakshminath

---

From: Charles Clancy <[email-masked]>
Date: Mon, 12 Mar 2007 16:27:11 -0500

FIPS 140-2 defers to SP 800-38a, which includes ECB, CBC, CFB, OFB, and 
CTR as allowable block cipher modes of operation.

The only RFC specifying AES-CTR (that I can find) is 3686, which uses it 
with IPsec ESP.

OpenSSL includes support.  See AES_ctr128_encrypt().

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 12 Mar 2007 17:01:15 -0700

Hi Charles,
Thanks for the quick update of the draft. A few comments inline.  

> Sent: Sunday, March 11, 2007 8:22 PM
> To: [email-masked]
> Subject: [Emu] EAP-GPSK update
> 
> All,
> 
> We've put together an update to the GPSK draft to address the 
> last call comments.  Below is a list of the identified issues 
> and their solutions. 
>   For a variety of issues we recommended no change with a 
> brief description.  If more detail is desired, we can 
> certainly discuss them further on the list.
> 

Well, I didn't really ask why not use EAP-TLS-PSK instead of GPSK :) I
was asking if there could be an explanation of some design goal that
really justified the use of GPSK over the other listed PSK-based
methods. Invariably, when an enduser is trying to pick between GPSK and
say, TLS-PSK, they're going to run through the relative advantages - all
things being equal, TLS-PSK may be preferred for reasons like what
Bernard was saying. But, my question is - are all things equal? The
design goals listed in the draft led me to believe that all things are
equal - but, I may be missing something. 

>              implicitly checked by validating the MAC on the 

This is not too clear to me. The TLS-suite of protocols seem to have
taken the route of not integrity protecting the EAP header, while almost
every other EAP method has included the EAP header into the MAC (cases
in point: EAP-AKA, EAP-SIM, EAP-PAX, EAP-SAKE). There is not adequate
information in those documents on why it is a good idea - perhaps
someone here can elaborate? 

Specifically in GPSK, the GPSK-Fail message seems to be the same in
either direction (peer to server or vice-versa). The EAP code seems to
be the only differentiating factor in it. If the EAP code is not
integrity protected, an entity can simply reflect the message back. With
GPSK-Fail, the effect of such reflection may be questionable, but, do we
have other cases like this that I might have missed? 

> Resolution: no change -- the KDF changes from MAC to Hash were

I couldn't find a discussion of this on the EMU list. Could you please
provide a summary of the advantages of going with Hash? 

>              guarantees cryptographic independence

Hmmm.. I'm not sure I understand - as far as I can tell, the same level
of cryptographic independence and the same kind of KDFs can be used in
either approach. If anything, it seems like the current construction
places some limitations on the KDFs, given the key and output length
requirements. I don't think either approach is necessarily bad - so,
this issue is more a matter of preference than anything. 

Vidya

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 13 Mar 2007 09:02:25 -0800

CBC mode is much more widely available in libraries than CTR mode.  RFC 3723 
specified CTR mode and this was probably a mistake.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 13 Mar 2007 10:21:37 -0700

Bernard Aboba wrote:
> CBC mode is much more widely available in libraries than CTR mode.  RFC 
> 3723 specified CTR mode and this was probably a mistake.
>  

CBC of course has been in use for a long time; no dispute there. 
However, CTR mode has been the mode specified for network access in a 
lot of "new" wireless access networks, including 802.11, 802.16, and 
3GPP2 link layers.

I would contend that CTR mode is more suitable -- compared to CBC -- for 
high-speed encryption also :).  Anyway, we are not discussing 3723 here.

---

From: "Charles Clancy" <[email-masked]>
Date: Sun, 18 Mar 2007 09:24:17 -0400 (EDT)

On Mon, March 12, 2007 8:01 pm, Narayanan, Vidya wrote:
> methods.

The design goals for EAP-GPSK are specified in the introduction.  GPSK vs
TLS-PSK isn't discussed, because it seems generally taboo to point out
other protocols' shortcomings and claim your superiority in an RFC.  I
think TLS-PSK's man shortcoming is that it wasn't the direction indicated
by the WG consensus.

> But, my question is - are all things equal? The

Probably more or less equal.  Method implementers have indicated that GPSK
is easier to implement.

> have other cases like this that I might have missed?

According to the draft, GPSK-Fail messages MUST be reflected, but only
because EAP is a request/response protocol.  The server's state machine
doesn't change due to the response.

> provide a summary of the advantages of going with Hash?

I don't think there was a discussion.  At the last IETF meeting Russ
suggested we talk to NIST about our KDF.  We did, they recommend changes,
and the draft was updated to reflect those changes.  The main advantage of
going with a hash is that it's in line with NISTs new set of key
derivation requirements, which use hashes rather than HMACs.  I'd wager
the security is probably identical.

---

From: Jouni Malinen <[email-masked]>
Date: Sun, 18 Mar 2007 08:10:57 -0700

> Resolution: switched AES ciphersuite to use SHA256

While I understand the desire not to use SHA-1, use of SHA256 with AES
ciphersuite is somewhat unfortunate due to the added requirement for a
new crypto primitive. Would you be willing to consider using
AES-128-CMAC here instead? That would make ciphersuite #1 depend only on
AES-based constructions and SHA256 would only be used for ciphersuite
#2 (which is optional).

PS.

With PK derivation removed from 6.2.3, there is no need for the last 32
octets of GKDF-192(MK, inputString) data and GDF-192 could be replaced
with GKDF-160 here. Since the requested length of the GDFK output is not
mixed into the Hash-Function input (should it?), this does not change
the derived keys, but is just a cleanup and small speed improvement
(drop one SHA256 operation).
 
-- 
Jouni Malinen                                            PGP id EFC895FA

---

From: "Charles Clancy" <[email-masked]>
Date: Sun, 18 Mar 2007 13:24:20 -0400 (EDT)

The problem is that the new KDF construction uses hashes instead of MACs.

---

From: Jouni Malinen <[email-masked]>
Date: Sun, 18 Mar 2007 10:52:25 -0700

> The problem is that the new KDF construction uses hashes instead of MACs.

Would use of CMAC with zero-key be acceptable to generate a hash
function for a KDF? Is there any publicly available document describing
why hashes should be used instead of MACs? I've only seen a comment
saying that this is because NIST says so for this particular
construction, but I have not seen any more details.

Getting more details on this would be interesting for other reasons,
too, since there are new designs (e.g., IEEE 802.11r) which are using
HMAC-SHA256 -based KDF. Since the 802.11r KDF construction is also
claimed to be compliant to NIST recommendations, it is somewhat odd to
see EAP-GPSK take the other direction with the reasoning that this came
from NIST..

---

From: "Charles Clancy" <[email-masked]>
Date: Sun, 18 Mar 2007 18:00:58 -0400 (EDT)

The problem with using a known key is that the function is invertable. 
The KDF doesn't work unless you can't invert it.

See: http://tools.ietf.org/html/draft-dang-nistkdf

Sounds like we should talk to our new A-D, since he's a coauthor on the
document from NIST.

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 19 Mar 2007 02:21:29 -0700

>see EAP-GPSK take the other direction with the reasoning that this came

I agree that the KDF usage in EAP-GPSK does not seem to be consistent with 
other standards that also claim NIST KDF compliance.

Maybe we should ask Tim Polk to attend the EMU WG meeting so we can ask him 
to explain this to us :)