The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method
draft-bersani-eap-psk-11

IANA Evaluation Comment:

IANA has questions about this document.

THe document says that IANA should register a new name space called EXT_Type
values. Should that registry be located within one of the existing EAP
registries or should the EXT_Type values be in a completely new registries?

Are there to be any initial registrations in the EXT_Type registry other than
value 255 for Experimental Use?

The document asks that a new EAP Method Type for EAP-PSK be established. In the
registry:

http://www.iana.org/assignments/eap-numbers

EAP-PSK has been assigned method type value 47. Can IANA assume that the
authors are satisfied that this part of their requirements is complete?

[Ballot comment]
Way too much of the description of the protocol is found only in the
diagrams.  If I were doing a more complete review or if this were
going for standards track I'd definitely hold a discuss on this issue.

I think it inappropriate to claim that passwords must not be used to
derive PSKs in the security considerations section and then to provide
an appendix describing how to do so.  The must should be reduced to a
should.

Sent to authors

In order to publish this document as an Individual Submission, an author needs to send email to rfc-editor@rfc-editor.org requesting publication. The IESG will not be shepherding the document itself. The IESG tracker state for this document will be moved to "AD is watching" until the RFC Editor picks it up. As for the IANA allocation, as Bernard mentioned, the current version has addressed review comments and will be allocated a type code accordingly.

Bernard, RFC 3748 says that a "Designated Expert can approve allocations once it seems clear that an RFC will be published." I suppose at a minimum this means the request to the rfc-editor has been sent. Have you already sent the request, or do you want to wait until after the rfc editor has acknowledged receipt of the document?

[Note]: 'Believe this should now be handled by the SEC ADs, given that EMU is chartered there and this is more closely related to that WG than EAP.' added by Mark Townsley

Email from Bernard WRT Expert Review Status for IANA assignment

-------- Original Message --------
Subject: RE: expert review status of EAP-PSK
Date: Thu, 2 Mar 2006 08:44:03 -0800 (PST)
From: Bernard Aboba
To: BERSANI Florent RD-CORE-ISS
CC: Jari Arkko ,        Tschofenig Hannes ,        "Walker, Jesse" ,        "W. Mark Townsley"
References: <941BA0BF46DB8F4983FF7C8AFE800BC203E4CA53@ftrdmel3.rd.francetelecom.fr>

Given that EAP-PSK has addressed the review comments, it should be
allocated an IANA Type Code.  I will send a message to IANA to that
effect.

On Thu, 2 Mar 2006, BERSANI Florent RD-CORE-ISS wrote:

>  Hi Jari & Bernard,
>
> I hope you are doing fine and I am looking forward to greeting you at IETF 65 in Dallas.
>
> I understand we all have our share of work to deal with but I am concerned about EAP-PSK not being appropriately put back on track (for now ;-)).
>
> As per the email below, the appointed expert reviewer, Jesse Walker, concluded his review with the approval of the new version of EAP-PSK (v10 available at http://www.ietf.org/internet-drafts/draft-bersani-eap-psk-10.txt).
>
> Still the IETF datatracker still indicates that it is under expert review with denial of IANA allocation of EAP type (https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11341&rfc_flag=0) and the EAP issues page (http://www.drizzle.com/~aboba/EAP/eapissues.html) still indicated status DENIED.
>
> Could you please indicate me any next steps I should take in order to have EAP-PSK put back on track for allocation of the EAP Type by IANA and publication as an experimental RFC?
>
> Do you have an idea of the timeline for EAP-PSK to be allocated its EAP type and put back on the IESG agenda?
>
> Many thanks in advance,
>
> Best regards,
>
> Florent Bersani
>
> -----Message d'origine-----
> De : BERSANI Florent RD-CORE-ISS
> Envoyé : dimanche 12 février 2006 14:35
> À : Jari Arkko; Bernard Aboba
> Cc : W. Mark Townsley; 'Walker, Jesse'; Tschofenig Hannes
> Objet : RE: expert review status of EAP-PSK
>
> Hi Jari, Hi Bernard,
> 
> Following Jesse's last comments in his expert review (see below), we have updated EAP-PSK (see attachment fyi before it appears on the archive).
> 
> If we understood correctly, provided Jesse does not say the contrary, we believe this now successfully concludes EAP-PSK expert review.
> 
> May we respectfully request that:
> a) EAP-PSK be allocated the EAP-Request/Response Type number by IANA (as per RFC 3748 process)
> b) EAP-PSK be resinserted in the appropriate place of the RFC editor queue from which it was temporarily extracted as per your request (to let its expert review finish without the IESG having to track its status)
> 
> Many thanks in advance,
> 
> Best regards,
> 
> Florent Bersani
> 
> P.S: see some comments in-line on Jesse's points.
>
> ________________________________
>
> De : Walker, Jesse [mailto:jesse.walker@intel.com] Envoyé : vendredi 13 janvier 2006 04:28 À : BERSANI Florent FT; Jari Arkko; Tschofenig Hannes Cc : Bernard Aboba; W. Mark Townsley Objet : RE: expert review status of EAP-PSK
>
>
>
> Gentlemen,
>
> Thanks for you patience with my review of EAP-PSK v8--only a month after promised. There were more interrupts than expected, which required me to reread numerous times.
>
> The new document is wonderful. I have a limited set of comments this time, all trivial, I think. Here they are:
>
> page 12: "EAP-PSK uses a 16-byte Pre-Shared Key called the PSK as its initial static credential." Actually, the credential includes the identities of the EAP peer and the EAP server.  is the EAP peer's credential. EAP peer NAI is the EAP server's name for PSK. Similarly,  is the EAP server's credential, and EAP server NAI is the EAP peer's name for PSK.
> [FB] agreed, section 2.2.1 updated:
>
> EAP-PSK uses a triplet (ID_P, ID_S, PSK) as its initial static credential.
>
> * ID_P is the EAP peer's NAI (see Section 3.2 (EAP-PSK Second Message) <  and Section 6.11 (Fragmentation) for more information on ID_P).
> * ID_S is the EAP server's NAI (see Section 3.2 (EAP-PSK Second Message) and Section 6.11 (Fragmentation)  for more information on ID_P).
> * PSK is a 16-byte pre-shared key. PSK is not a session key: it is a key that is used to derive static long-lived keys for EAP-PSK.
>
> page 12: "The security properties of the protocol may be compromised if it has wider distribution." "may be" is an understatement. If the key is shared further, then it loses its ability to provide any authentication. Replace "may be" with "is". It is worth adding a note that EAP-PSK shares this property with all other symmetric key methods (including all password based methods), all marketing claims by people who don't know what they are talking about to the contrary.
>
>
> [FB] agreed, section 2.2.1 updated:The security properties of the protocol is compromised if it has wider distribution. Please note that EAP-PSK shares this property with all other symmetric key methods (including all password based methods). 
>
> page 15: "In case AES-128 is deprecated for security reasons, EAP-PSK should also be deprecated and a cut-and-paste EAP-PSK' should be defined with another block cipher." A note should be added to avoid chosen protocol attacks when doing this.
> [FB] agreed, section 2.2 updated: The use of a different EAP-Request/Response Type number for EAP-PSK' will prevent this new method from being vulnerable to chosen protocol attacks.
>
> page 18: "Figure 4: Overview of AKEP2". The protocol depicted is actually named MAP1 in [15]. Message 2 should carry an encrypted key to be called AKEP2. (And actually MAP1 does not include A's id in message 1).
> [FB] agreed (apart the remark on carrying an encrypted key which applies to AKEP1 but not AKEP2), section 2.2.2 updated
>
> It is also worth noting that [14] (Bellare, M. and P. Rogaway, "Entity Authentication and Key Distribution," 1994.)  focuses on cryptography and not on designing a real-life protocol. Thus, as noted in subsection "Out-Of-Band-Data" of [14] (Bellare, M. and P. Rogaway, "Entity Authentication and Key Distribution," 1994.)  , Alice has to send A, its identity, to Bob so that Bob may select the appropriate credential for the sequel of the conversation. This leads to a slightly complemented version of AKEP2 for EAP-PSK as depicted in Figure 5 (Overview of AKEP2 with out-of-band data)  .
>
> 
>
> page 19: "It has been recommended by the NIST under the name CMAC ." Then why continue to call it OMAC1? At some point people will forget what OMAC1 is.
> [FB] agreed, whole document updated and cmac entry added to section 1.2
>
> page 24: It would be useful to protect the type and flags field to protect against chosen a chosen protocol attack. This is important, because it seems likely that EAP-PSK will be considered in peer-to-peer settings such as meshes, where either party can be both a server and a peer. The EVE1 protocol (same as MAP1, but with A and B's identities in message 2 reversed) is an example of such a protocol that could be implemented that could be used by a man-in-the-middle to compromise the responder. (The Bellare-Rogaway model assumes that the two parties execute only a single protocol.) Protecting the "protocol" number specified by the type field would preclude this vulnerability.
> [FB] see section 2.2.3, type and flags are protected in the protected channel
>
> page 24. Somewhere it should be noted that both the peer and the server must commit to their RAND_S and RAND_P to protect their partners from flooding attacks. Section 6.8 would be one appropriate place to note this.
> [FB] agreed, section 6.8 updated Please note that both the peer and the server must commit to their RAND_S and RAND_P to protect their partners from flooding attacks.
>
> page 46. As noted above, it would be fair to claim that EAP-PSK provides mutual authentication if it is based on a pairwise PSK of sufficient strength. If the PSK is not pairwise or not sufficiently strong, then it does not provide authentication. In this way it is no different than other authentication protocols based on pre-shared keys, despite all marketing claims to the contrary.
> [FB] agreed, section 6.1 updated EAP-PSK provides mutual authentication if it is based on a pairwise PSK of sufficient strength. If the PSK is not pairwise or not sufficiently strong, then it does not provide authentication. In this way EAP-PSK is no different than other authentication protocols based on pre-shared keys.
>
> page 47: Similarly, a strong pairwise PSK is required to assert message integrity.
> [FB] agreed, section 6.3 updated EAP-PSK provides integrity protection if it is based on a pairwise PSK of sufficient strength. If the PSK is not pairwise or not sufficiently strong, then it does not provide authentication. In this way it is no different than other authentication protocols based on pre-shared keys.
>
> 
>
> page 47. It would be fair to say that EAP-PSK provides replay protection if the nonces are cryptographically random, i.e., unpredictable to the adversary, and not otherwise. Hence cryptographic randomness is a requirement for correct implementation of the protocol.
> [FB] as per bellare-rogaway papers, although the random numbers RA and RB must be random for the mutual authentication part, then nonce N used in the protected channel to provide replay protection of the communication over the protected channel may well be a counter, which it is in EAP-PSK
>
> page 50: If you do not include a note requiring the peer committing to the RAND_P value it selects for a session and the server committing to the RAND_S value it selects for the session, I cannot understand how the design avoids denial-of-service attacks based on flooding lots of different random values.
> [FB] agreed, section 6.8 updated
>
>
> > -----Original Message-----
> > From: BERSANI Florent SCR [mailto:florent.bersani@francetelecom.com]
> > Sent: Tuesday, December 13, 2005 6:51 AM
> > To: Walker, Jesse; Jari Arkko; Tschofenig Hannes
> > Cc: Bernard Aboba; W. Mark Townsley
> > Subject: RE: expert review status of EAP-PSK
> >
> >
> > Hi Jesse,
> >
> > Resending as per your request see below - how come this fell off your
> > stack ;-)
> >
> > You can look at an alternative presentation as promised at IETF 63 at
> > http://www.tschofenig.com:8080/eap-psk/
> >
> > Hannes and I would be glad to work with you on resolving the pending
> > issues.
> >
> > Best,
> >
> > Florent
> >
> >
> > -----Message d'origine-----
> > De : BERSANI Florent SCR/BBES
> >
> > Envoyé : lundi 18 juillet 2005 08:46
> > À : 'jesse.walker@intel.com'
> > Cc : 'Tschofenig, Hannes'; 'jari.arkko@piuha.net'
> > Objet : Your review of EAP-PSK - section 1 AK and KDK
> >
> > Hi Jesse,
> >
> > Hard to get my hands back to work after a long sabbatical leave. Anyway,
> > it is a pleasure to benefit from your review of EAP-PSK.
> >
> > Pls find below first comments to your review.
> >
> >
> > Hannes and I have updated the draft accordingly, pls find it attached to
> > this mail before it appears in the archive. Sorry for the xml snippets in
> > my text below.
> >
> > I don't know how we should deal with this: I'd recommend starting the
> > discussion offline and moving to the mailing list once we have reached
> > resolution of the open issues or when we have some questions/disagremments.
> > Would this be OK for you?
> >
> > For the sake of keeping the emails of reasonable lenght I have split my
> > answer according to your review section numbering
> >
> > I have some questions on the following notions you are using:
> >
> > A) Forward secrecy. I am not sure I get your point: I am not familiar with
> > forward secrecy although I know perfect forward secrecy. From a protocol
> > point of view, although it is safer to delete unused keys (e.g. PSK),
> > having PSK or AK,KDK gives exactly the same rights.
> >
> > B) Prefix attack. Could you explain the prefix attack on AK and KDK you
> > are alluding to?
> >
> > Pending my better understanding of what you call prefix attacks, I'd like
> > to discuss some points you raise on key naming and separation.
> >
> > Regarding key naming, I think that Hannes and I have made clear that the
> > EAP-PSK keys must not be used by any other protocol and how an EAP server
> > and an EAP peer identify the right keys to use with each other. Including
> > explicit key names like (EAP-PSK, PSK, EAP server NAI, EAP peer NAI) does
> > not help much as we cannot guarantee that the encoding we would define
> > will be unambiguous with other key naming schemes (for instance key naming
> > used by some FAP protocol or whatever). Moreover, I do not think that key
> > names, should we include any, would be used by implementers. Furthermore,
> > we have no features within EAP-PSK, contrary to some other protocols which
> > need key identifiers e.g. IEEE 802.11i, that need to refer to EAP-PSK keys.
> > Suggestion is thus no to including any "official" key naming scheme.
> >
> > Regarding inclusion of identity within the AK and KDK derivation, we had
> > chosen not to include it for the sake of simplicity. I agree that this
> > could prove to be a nice feature that saves the day of poor administrators
> > that share the same PSK across many devices. Let us think a bit more on
> > how we can do this (thx BTW for your nice suggestions).
> >
> > Best,
> >
> > Florent
> >
> > 1. AKA and KDK issues
> >
> > The text should point out more explicitly that AK and KDK are static long-
> > lived keys, i.e., not session oriented.
> >
> > [FB] OK, I've added the following text to 2.1.1 and 2.1.1.1 and 2.1.1.2:
> >
> > "EAP-PSK uses a 16-byte Pre-Shared Key called the PSK as its initial
> > static credential. PSK is not a session
> > key: it is a key that is used to derive static long-lived keys for EAP-PSK.
> >
> > This PSK is used, as shown in , to derive
> >      two 16-byte static long-lived subkeys, respectively called the
> > Authentication Key (AK)
> >      and the Key-Derivation Key (KDK).
> >
> >      This derivation MUST only be done once: it is called the key setup.
> > For an explanation of why PSK
> >
> >      is not used a static long-lived key but only as the initial keying
> > material from which the static long-lived
> >      keys, AK and KDK, that are actually used by the protocol EAP-PSK,
> > see "
> >
> > "AK is a static long-lived key derived from the PSK, see  > />. AK is not a session key.
> >
> >
> >    The EAP server and EAP peer identify the
> >
> >      correct AK to use with each other thanks to their respective NAIs.
> > This means that there MUST only be at
> >      most one AK shared between an EAP server using a given server NAI
> >      and an EAP peer using a given peer NAI. This is the case when there
> > is at most one PSK shared between an EAP server using a given server NAI
> >      and an EAP peer using a given peer NAI, see  > />.
> >
> >
> >      The EAP peer chooses the AK to use based on the EAP server NAI
> > that has been sent by the EAP server
> >
> >      in the first EAP-PSK message (namely ID_S, see  > target="stauthent" />) and the EAP peer NAI it chooses
> >      to include in the second EAP-PSK message (namely ID_P, see  > target="stauthent" />)."
> >
> > And similarly for KDK.
> >
> > Does that adress your concerns?
> >
> > Deleting the PSK SHOULD be a SHOULD and the default action.
> >
> > [FB] OK, included the SHOULDs
> >
> > -----Message d'origine-----
> > De : BERSANI Florent SCR/BBES
> >
> > Envoyé : lundi 18 juillet 2005 08:48
> > À : 'jesse.walker@intel.com'
> > Cc : 'Tschofenig, Hannes'; 'jari.arkko@piuha.net'
> > Objet : Your review of EAP-PSK - section 2 TEK, MSK, and EMSK issues
> >
> > Hi Jesse,
> >
> > Pls find below our first comments based on section 2 of your review.
> >
> > Again I'd like to understand what you mean by "prefix attacks" ("Since the
> > length is not included in the key derivation, prefix attacks are again
> > possible against the key derivation algorithm itself).
> >
> > Best,
> >
> > Florent
> >
> >
> > 2. TEK, MSK, and EMSK issues
> >
> > The derivation of the TEK, MSK, and EMSK depend on only RAND_S and KDK.
> > This means the peer assumes (i.e., "trusts") that the server generates a
> > statistically unique RAND_S for each session. If the server fails to
> > generate a statistically unique RAND_S, then the TEK, MSK, and EMSK are
> > compromised on each repeated session.
> >
> > [FB] Actually, TEK, MSK and EMSK only depend on RAND_P (we've amended some
> > text in 2.2.2 to clarify) and KDK, which is noted in 6.6 of the draft. Let
> > us highlight two reasons why we made this choice:
> > A) most obviously we wanted to stick to AKEP2
> > B) we wanted to keep the protocol as simple as possible (implementability,
> > efficiency) and we assumed that we could live off without this feature,
> > provided we mentioned it as a warning. As the TEK, MSK and EMSK are only
> > to be used if mutual authentication is successful and this mutual
> > authentication involves randomness from the server side, risks should be
> > "limited"
> >
> > Do you think this is a blocking point?
> >
> >
> >
> >
> > -----Message d'origine-----
> > De : BERSANI Florent SCR/BBES
> >
> > Envoyé : lundi 18 juillet 2005 08:49
> > À : 'jesse.walker@intel.com'
> > Cc : 'Tschofenig, Hannes'; 'jari.arkko@piuha.net'
> > Objet : Your review of EAP-PSK - section 3 protocol issues
> >
> > Hi Jesse,
> >
> > Pls find below our first comments based on section 3 of your review.
> >
> > Best,
> >
> > Florent
> >
> > I tend to (respectfully disagree) with the points you mention:
> >
> > (a) ID_S is not explicity included in the second message. However, it is
> > included in MAC_P = OMAC1-AES-128(AK, ID_P||ID_S||RAND_S||RAND_P), as
> > Thomas Otto pointed out on the mailing list. We could however include ID_S
> > without any problem (just by making sure to update the appropriate limit
> > on the length of the NAI to avoid fragmentation) but I do not see the need
> > to do so.
> >
> > (b) Again, I think there is some confusion between what is included
> > explicitly and what is cryptographically protected. My claim is that we
> > fully respect AKEP2 regarding cryptographic protection (i.e. the MACs of
> > EAP-PSK are exactly the MACs of AKEP2) but we take some liberty on the
> > explicit content of the message (because we can reconstruct this content
> > without trouble). The server MACs the peer random number in message 3:
> > MAC_S = OMAC1-AES-128(AK, ID_S||RAND_P)
> >
> > (c) Section 2.2.3 states that The Tag is a MAC that protects both the
> > Header and the Plain Text
> >
> >    Payload. So the protection comes from EAX. We've included the following
> > clarifying text "the PCHANNEL_S_0 and PCHANNEL_P_1 fields of the third and
> > fourth EAP-PSK messages contain a MAC computed thanks to
> >      TEK that protects the integrity of the messages. For a detailed list
> > of the fields of the messages that are integrity protected
> >      please refer to ." We agree that it would
> > be nice to find some notation to show What is integrity protected and what
> > is not but we felt that the added complexity to do so would in the end not
> > benefit to the reader. We are however looking again at this issue.
> > We do not see a case where your cut and paste attack could apply. Could
> > you please clarify? It is true that there is no explicit crypto binding
> > between the MAC_S and P_CHANNEL_S_0 but there is no need to do so: the
> > only ting that matters is that the conversation be "coherent", which is
> > the case as PCHANNEL_S_0 is computed according to a TEK which is only put
> > in place if MAC_P is correct.
> >
> >
> >
> >
> > -----Message d'origine-----
> > De : BERSANI Florent SCR/BBES
> >
> > Envoyé : lundi 18 juillet 2005 08:50
> > À : 'jesse.walker@intel.com'
> > Cc : 'jari.arkko@piuha.net'; 'Tschofenig, Hannes'
> > Objet : Your review of EAP-PSK - section 4 security bounds
> >
> > Hi Jesse,
> >
> > Pls find below our first comments based on section 4 of your review.
> >
> > Thks for your estimates of the key lives, with which we concure.
> >
> > Best,
> >
> > Florent
> >
> > 4. Security Bounds
> >
> > Page 39, Section 6.5 asserts that EAP-PSK is not subject to dictionary
> > attack. This is not true when the PSK is computed from a feasibly searched
> > key space, e.g., when it is, or is derived from, a password.
> >
> > [FB] that's why section 6.5 says:
> >
> > "Indeed, the PSK used by EAP-PSK
> >
> >    must not be derived from a password. Derivation of the PSK from a
> >
> >    password may lead to dictionary attacks."
> >
> > Would you like us to include some more text?
> >
> > The text exhibits some confusion about how to measure the EAX key strength.
> >
> >
> > [FB] I don't know to which part of the draft you are alluding to. Maybe
> > the part where we bound the number of messages that are exchanged? If this
> > is the case, then the bound is only for the sake of replay protection not
> > life of the key.
> >
> > It is sufficient to say that EAP-PSK appears as robust in this dimension
> > as any other EAP method.
> >
> > [FB] :-))
> >
> >
> >
> >
> > -----Message d'origine-----
> > De : BERSANI Florent SCR/BBES
> >
> > Envoyé : lundi 18 juillet 2005 08:49
> > À : 'jesse.walker@intel.com'
> > Cc : 'Tschofenig, Hannes'; 'jari.arkko@piuha.net'
> > Objet : Your review of EAP-PSK - section 3 retries, replays and errors
> >
> > Hi Jesse,
> >
> > Pls find below our first comments based on section 3 of your review.
> >
> > Best,
> >
> > Florent
> >
> > 3. Retries, Replays, and Errors
> >
> > It will be necessary somewhere to specify how to handle retransmissions,
> > i.e., we need a standardized treatment of "retries" as distinct from
> > "replays". This holds for both the messages in the base protocol, and
> > extended messages protected by the nonce N. Retries should cause the
> > receiver to retransmit, while replays should be discarded. The difference
> > between the two will always be an arbitrary distinction, but is needed for
> > interoperability's sake.
> >
> > [FB] My understanding of EAP is that it is the EAP layer that deals with
> > retransmissions so EAP-PSK should never bother to "resend" a message.
> > Regarding, an invalid EAP-PSK message meaning a message that is incorrect
> > from a syntaxic or a cryptographic point of view, the behavior is that the
> > message be silently discarded until either a valid message is received or
> > there is a timeout/threshold of wrong messages that are received. We've
> > included the following text to clarify
> >
> >
> > t>When a party receives an EAP-PSK message, it checks that the message
> >
> > t>is syntaxically valid in accordance with
> >    the message formats defined in . If the message
> > is syntaxically incorrect, then it is silently discarded.Then it checks
> > the cryptographic validity of this message,
> >
> >    i.e. it checks the MAC(s), namely
> >   
> >    If the received message is the first EAP-PSK message, there is no
> > MAC to check as none is included in message 1.
> >    If the received message is the second EAP-PSK message, the validity
> > of MAC_P is checked.
> >    If the received message is the third EAP-PSK message, the validity
> > of MAC_S is checked and then the validity of the Tag included in
> > P_CHANNEL_S_0 is checked.
> >      The validity checks must be done in this order to avoid
> > unnecessarily deriving TEK, MSK and EMSK in case MAC_S is invalid,
> >
> >      meaning that mutual authentication has failed. Indeed, TEK is used
> > to verify the validity of the Tag included in P_CHANNEL_S_0.
> >    If the received message is the fourth EAP-PSK message, the validity
> > of the Tag included in P_CHANNEL_P_1 is checked.
> >    If the received message is an EAP-PSK message different from the
> > first four ones, then validity of the Tag included in P_CHANNEL is
> > checked
> >       
> >    In case a validity check fails, the message is silently discarded.
> > There can be a counter to track the number of silently
> >    discarded messages . In case, there is an encrypted
> > payload in the message (namely in the PCHANNEL attribute),
> >    then the encrypted payload is decrypted. Then, if the decrypted payload
> > is syntaxically incorrect then the message is silently discarded.
> >
> >
> > And:
> >
> >
> > For the sake of simplicity and denial of service resilience, EAP-PSK
> > has chosen not to
> >    include any error messages. Hence, an "invalid" EAP-PSK message is
> > silently discarded. Although this makes
> >    interoperability testing and debugging harder, this leads to simpler
> > implementations and does not open any
> >    venue for denial of service attacks.
> >
> >
> >
> > The document uses sequence numbers for the extended portion of the
> > protocol, but fails to indicate the sequence spaces associated with each,
> > how they are initialized, and how they are used to detect replays.
> > I believe that there needs to be different sequence spaces for each of the
> > two logical half-duplex channels, but perhaps the request/response nature
> > of EAP will save us from this fate.
> >
> > [FB] In section 2.2.3 we can read The nonce N is used to provide
> > cryptographic security to the
> >
> >    encryption and data origin authentication as well as protection replay.
> >
> >    Indeed, N is a 4-byte sequence number starting from <0> that is
> >
> >    monotonically incremented at each EAP-PSK message within
> >    one EAP-PSK dialog, except retransmissions of course.
> >
> >   
> >    N was taken to be 4 bytes to avoid 16-byte
> >
> >    arithmetic. Since EAX uses a 16-byte nonce, N is padded with 96 zero
> >
> >    bits for its high order bits.
> >     
> >    For cryptographic reasons, N is not allowed to wrap around. In the
> > unlikely, yet possible, event of the server sending an EAP-PSK message
> > with
> >
> >    N set to <2**32-2>, it must not send any
> >
> >    further message on this protected channel, which would cause to reuse
> > the value 0.
> >    Either the conversation is
> >
> >    finished after the server receives the EAP-PSK answer from the peer
> >
> >    with N set to <2**32-1> and the server
> >
> >    proceeds (typically by sending an EAP-Success or
> >
> >    Failure), or the conversation is not finished and must then be
> >
> >    aborted (a new EAP-PSK dialog may subsequently be started to try
> >
> >    again to authenticate).
> >   
> >    Thus, the maximum number of messages that can be exchanged over the
> >
> >    same protected channel is 2**32 (which should not be a limitation in
> >
> >    practice as this is approximately equal to 4 billions).
> >   
> >
> >
> > Thus, the peer messages include an odd nonce and the server ones an even.
> > I've added some text to the replay protection section to clarify
> >
> > EAP-PSK provides replay protection thanks to the Nonce N of its
> > protected channel
> >      (see ). This nonce is initialized to 0 by
> > the server and monotonically incremented by one by the party that receives
> > a valide EAP-PSK message.
> >      For instance, after receiving from the server a valid EAP-PSK
> > message with Nonce set to x, the peer will answer with
> >      an EAP-PSK message with Nonce set to x+1 and wait for an EAP-PSK
> > message with Nonce set to x+2. A retransmission
> >      of the server's message with Nonce set to x, would cause the peer
> > EAP layer to resend the message in which
> >
> >      Nonce was set to x+1, which would be transparent to the EAP-PSK
> > layer.
> >
> > The protocol seems to protect itself from reflection attacks by including
> > the EAP header in the MAC. This is a detail the text glosses over and
> > needs to be made explicit, especially in extended authentication
> > protection provided by EAX, as it will likely be missed by many
> > implementers.
> >
> > [FB] I am not sure how to include text to cover this. I've added
> >
> >
> > t>EAP-PSK provides protection against reflection attacks in case of an
> > extended authentication because:
> >       
> >    It integrity protects the EAP header (which contains the indication
> > Request/Response.
> >    It includes two separate spaces for the Nonces: the EAP server only
> > receives messages with odd nonces, whereas the EAP peer only received
> > messages with even nonces.
> >   
> >       
> >
> > One notable omission from the spec is failure processing. As an example,
> > what does the server do if it receives a message 2 for a protocol instance
> > that it has not initiated? Experience shows that different implementers
> > will handle such messages in different ways, almost always to the
> > detriment of interoperability.
> >
> > [FB] you're right. Tentative fix is explained above: silently discard.
> >
> >
> >
> >
> > -----Message d'origine-----
> > De : BERSANI Florent SCR/BBES
> >
> > Envoyé : lundi 18 juillet 2005 08:51
> > À : 'jesse.walker@intel.com'
> > Cc : 'Tschofenig, Hannes'; 'jari.arkko@piuha.net'
> > Objet : Your review of EAP-PSK - section 5 odds and ends
> >
> > Hi Jesse,
> >
> > Pls find below our first comments based on section 5 of your review.
> >
> > Best,
> >
> > Florent
> >
> >
> > 5. Odds and Ends
> >
> > Here are a number of miscellaneous comments:
> >
> > It would be worth considering replacing OMAC1 by CMAC. NIST SP800-38B [2]
> > defines CMAC as the "approved" CBC-MAC variant.
> >
> > [FB] agreed as noted in SP800-38B, OMAC1 and CMAC are equivalent. I've
> > added the mention of CMAC. I favor leaving
> > OMAC1 in place as there is some coherence with EAX.
> >
> >
> > Page 17: What specific security claim is being made by the phrase "proof
> > of security"? Please detail the security model and assumptions used, and
> > also the specific claims being made based on these. The proof may or may
> > not be relevant in the present context.
> >
> > [FB] I agree that merely saying "proof of security" is not enough. Yet,
> > EAP-PSK does not seem to me the right place to make a lecture on provable
> > security. So following your remark, our proposed fix is to replace
> > offending Text with:
> > "It also enjoys up to date review by the cryptographic community,
> >
> >    especially using provable security concepts."
> >
> > Page 21: The design requires the EAP server to expose its identity and to
> > use the same identity with each peer, unless there is something in the
> > EAP-Response/Identity triggering the method that tells it otherwise.
> > This is a subtle configuration constraint that may not be evident to
> > administrators deploying the protocol.
> >
> > [FB] Good point.
> >
> >
> > Text added:
> > In the first EAP-PSK message, the EAP server asserts its identity.
> > Given that the EAP-Request/Identity
> >              and EAP-Response/Identity may not be assumed to have occured
> > prior to this sending and that the response included
> >                in EAP-Response/Identity (if this EAP Identity exchange
> > takes) place may not contain the actual NAI the peer shall
> >                use with EAP-PSK, this means that an EAP server implementing
> > EAP-PSK must use the same EAP server NAI
> >                for all EAP-PSK dialogs with any EAP peer implementing EAP-
> > PSK.
> >
> > Since EAP-PSK aims at simplicity, this should not be a limitation.
> >
> > Page 23, Figure 9: The hashed RB value constructed above that incorporates
> > both RAND_S and RAND_P seems like a better session identifier than the
> > RAND_S in messages 3 through 2i+1, because it is computationally
> > infeasible for either party to force it to a value used by a prior
> > protocol instance. Beginning in message 4, the P_CHANNEL_P_k needs to be
> > protected by EAX using the TEK.
> >
> > [FB] Although nicer from a crypto point of view, this means that the
> > session identifier would only be known after the second message. Keeping
> > it constant appears to be simpler. Also, since the randomness assumption
> > is crucial for security, Although I agree it is a nice investigation field
> > to have crypto protocols resilient against weaknesses in their assumptions,
> > I feel that here this would be too much for EAP-PSK. Don't you think?
> >
> > Page 25, Flags field: The figure of the Flags field needs to be cleaned up.
> > It should be relabled to have only 8 bits, not 9. And the unreserved field
> > should be widened from 1 to 2 bits.
> >
> > [FB] I don't get this one as the version I seems to have Figure 11 OK.
> >
> > Page 35: What happens if the tunneled method fragments?=09
> >
> > [FB] see section 6.10 "Extensions that require sending a payload larger
> > than 960 bytes should provide
> >    their own fragmentation and reassembly mechanism" also in section 4.2
> > it is said that the EAP extension may only send 960 byte payloads at most.
> >
> > Page 38, Section 6.1: Until message 2 is fixed to include both ID_S and
> > ID_P, EAP-PSK does not provide mutual authentication.
> >
> > [FB] disagree with this one, see section 3 of your review
> >
> > Page 38, Section 6.2: The assertion that the R field is protected does not
> > yet appear warranted, given that the sequence spaces have not yet been
> > completely specified, so replay and perhaps reflection attacks appear to
> > be possible, and further given that the message 1 and 3 constructions
> > allow an attacker to replay old EAP-PSK messages. The existing text would
> > become correct when these issues are addressed.
> >
> > [FB] The R field is protected by EAX, clarifying text has been added:
> >
> > This 2-bit R flag is protected because it is encrypted and integrity
> >
> >    protected by the EAX mode of operation, see .
> >
> > Page 42, Section 6.7: Since message 1 is unprotected, it can be forged by
> > an adversary. Once it chooses to initiate an EAP_PSK instance, the server
> > must commit to a value RAND_S to enable the peer to recover from a denial-
> > of-service attack based on flooding forged message 1s. This is a
> > reasonable constraint to put on server implementations. It will require
> > you to fill out the missing discussion on the difference between retries
> > and replays. RAND_S remains constant across retries, but is changed on all
> > protocols instances the server classifies as "new". The receiver should
> > retransmit the last message if it receives a duplicate within some retry
> > message, and declare a duplicate a replay otherwise.
> >
> > [FB] I agree, does the filling I've added for retries clarifies?
> >
> > Page 43, Section 6.8: Actually session independence comes about by
> > choosing non-repeating instance identifiers .
> > The current protocol lacks this property due to its inability to protect
> > against replayed messages 1 and 3. When this is fixed, the protocol will
> > have session independence.
> >
> > [FB] It is not possible IINM to replay message 3. So there is session
> > independance if we assume Rand_S and Rand_P to be chosen at randome, isn't
> > there?
> >
> > Page 43, Section 6.9. The protocol design explicitly assumes that neither
> > AK nor KDK are shared beyond the two parties utilizing them. AK loses its
> > efficacy to mutual authenticate the peer and server with each other when
> > it is shared. Similarly, the derived TEK, MSK, and EMSK lose their value
> > for authentication when KDK is shared with a third party.
> >
> > [FB] I've inserted your text.
> >
> > Page 43, Section 6.12: It should be easy to add a "fast reconnect" if the
> > server and peer maintain the TEK and their replay counters. Whether this
> > is valuable is dubious, however.
> >
> > [FB] Since it was dubious, we preferred not to ;-)
> >
> > Page 46, Section 6.16. I think it is a mistake to not define a
> > cryptographic binding mechanism of a key producing inner method and EAP-
> > PSK. It is easy to do, and it makes EAP-PSK safe to use key deriving inner
> > methods. Subsidiary methods are becoming more important, as IT departments
> > are moving to evaluation of the patch level of devices before they allow
> > data to pass.
> >
> > [FB] I think that since EAP-PSK is really meant to be simple, I would be
> > suprised that inner methods that need key binding use EAP-PSK. I think
> > that a binding mechanism could be implemented as an EAP-PSK extension if
> > the need to do so arise. But for now, we do prefer to keep EAP-PSK as
> > simple as possible. Is it OK with you?
> >
> >
> >
> > > -----Message d'origine-----
> > > De : Walker, Jesse [mailto:jesse.walker@intel.com]
> >
> > > Envoyé : mardi 13 décembre 2005 15:42
> > > À : Jari Arkko; Tschofenig Hannes; BERSANI Florent SCR
> > > Cc : Bernard Aboba; W. Mark Townsley
> > > Objet : RE: expert review status of EAP-PSK
> > >
> >
> > > Please resend. This item fell off the end of the priority queue.
> > >
> >
> > > > -----Original Message-----
> > > > From: Jari Arkko [mailto:jari.arkko@piuha.net]
> > > > Sent: Tuesday, December 13, 2005 5:53 AM
> > > > To: Walker, Jesse; Tschofenig Hannes; BERSANI Florent SCR/BBES
> > > > Cc: Bernard Aboba; W. Mark Townsley
> > > > Subject: expert review status of EAP-PSK
> > > >
> >
> > > > Jesse,
> > > >
> >
> > > > If I have understood correctly, we are still in the process of
> >
> > > > resolving your expert review comments for EAP-PSK. I believe Hannes
> >
> > > > had some questions back to you (maybe you can resend them,
> >
> > > Hannes?),
> >
> > > > could you take a look at the so that the authors and you
> >
> > > can agree on
> >
> > > > what needs to change and why. Lets use the eap list so that
> >
> > > others can
> >
> > > > participate too, if they want to.
> > > >
> >
> > > > Also, Florent and Hannes -- we are getting regular e-mails from the
> >
> > > > IESG asking what the status is and what they should do with this
> >
> > > > individual submission. Can we agree that we're pulling the
> >
> > > draft from
> >
> > > > IESG processing until we've resolved the expert review
> >
> > > satisfactorily?
> >
> > > > The EAP process defined in RFC 3748 is that you have to pass the
> >
> > > > expert review before you can get an IANA allocation.
> > > >
> >
> > > > --Jari
> > > >
> >
> > >
> >
> >
> >
> > ********************************
> > Ce message et toutes les pieces jointes (ci-apres le "message") sont
> > confidentiels et etablis a l'intention exclusive de
> > ses destinataires.
> > Toute utilisation ou diffusion non autorisee est interdite.
> > Tout message electronique est susceptible d'alteration. Le Groupe France
> > Telecom decline toute responsabilite au titre de
> > ce message s'il a ete altere, deforme ou falsifie.
> > Si vous n'etes pas destinataire de ce message, merci de le detruire
> > immediatement et d'avertir l'expediteur.
> > *********************************
> > This message and any attachments (the "message") are confidential and
> > intended solely for the addressees. Any unauthorised
> > use or dissemination is prohibited.
> > Messages are susceptible to alteration. France Telecom Group shall not be
> > liable for the message if altered, changed or
> > falsified.
> > If you are not the intended addressee of this message, please cancel it
> > immediately and inform the sender.
> > ********************************
>

Email to Authors from Chairs

-------- Original Message --------
Subject: expert review status of EAP-PSK
Date: Tue, 13 Dec 2005 15:53:02 +0200
From: Jari Arkko
To: Walker, Jesse , Tschofenig Hannes , BERSANI Florent SCR/BBES
CC: Bernard Aboba , "W. Mark Townsley"


Jesse,

If I have understood correctly, we are still in the process
of resolving your expert review comments for EAP-PSK. I believe
Hannes had some questions back to you (maybe you can resend
them, Hannes?), could you take a look at the so that the authors
and you can agree on what needs to change and why. Lets use
the eap list so that others can participate too, if they want to.

Also, Florent and Hannes -- we are getting regular e-mails from
the IESG asking what the status is and what they should do with
this individual submission. Can we agree that we're pulling the
draft from IESG processing until we've resolved the expert
review satisfactorily? The EAP process defined in RFC 3748 is
that you have to pass the expert review before you can get an
IANA allocation.

--Jari

CURRENT STATUS

Asked EAP WG for review. Response was that Expert Review from IANA denied a code point. Advice from chairs to move to EMU. EMU ADs denied request. Document authors unresponsive according to chairs. Pressure to move to dead state, but I do not want to based on IANA code point denial. Looking for real review from EAP WG or Chairs if I am going to kill this doc.

-------- Original Message --------
Subject: RE: Process question on draft-bersani-eap-psk (Experimental)
Date: Tue, 13 Dec 2005 14:56:01 +0100
From: Jari Arkko (JO/LMF)
To: Mark Townsley , Bernard Aboba
CC: Sam Hartman , Russ Housley , Margaret Wasserman


I sent a reminder today to Jesse, asking him to answer the
questions authors had on the expert review, and to the authors,
asking them to repost their questions. Also, I asked confirmation
from the authors that they are not pushing this through the IESG
before the exprt review is over and agreed upon.

--Jari

-----Original Message-----
From: Mark Townsley [mailto:townsley@cisco.com]
Sent: 13. joulukuuta 2005 15:49
To: Bernard Aboba
Cc: Sam Hartman; Jari Arkko (JO/LMF); Russ Housley; Margaret Wasserman
Subject: Re: Process question on draft-bersani-eap-psk (Experimental)


Jari, Bernard,

It looks like either way this document is going to move to dead status.
I'd like to document the review objections in the tracker. I would be
more comfortable killing this document if it were an EAP WG review (as I
believe I requested in the beginning) as opposed to just an Expert
Review for an IANA code point behind it. Reason being, is that we get a
lot of flak in other groups about the IANA Experts holding too much
"power" - this would be a clear case where the IANA code point
determined the fate of a document pretty much on its own.

At the very least, I would like the EAP WG Chairs to give me a review
stating why the document should not advance as it is. Better to pass
this by the list as well.

Thanks,

- Mark

Bernard Aboba wrote:

>>So, the IESG agreed to shepherd this doc with review through the EAP
>>WG. I'm hearing that the EAP WGs recommendation is "Do Not Publish" -
is that correct?
>>   
>>
>
>No.
>
>draft-bersani-eap-psk has never been reviewed by the EAP WG.  Under the

>process described in RFC 3748 Section 6, the authors requested a Type
>Code allocation review.  Here is the process:
>
>  For registration requests where a Designated Expert should be
>  consulted, the responsible IESG area director should appoint the
>  Designated Expert.  The intention is that any allocation will be
>  accompanied by a published RFC.  But in order to allow for the
>  allocation of values prior to the RFC being approved for
publication,
>  the Designated Expert can approve allocations once it seems clear
>  that an RFC will be published.  The Designated expert will post a
>  request to the EAP WG mailing list (or a successor designated by the
>  Area Director) for comment and review, including an Internet-Draft.
>  Before a period of 30 days has passed, the Designated Expert will
>  either approve or deny the registration request and publish a notice
>  of the decision to the EAP WG mailing list or its successor, as well
>  as informing IANA.  A denial notice must be justified by an
>  explanation, and in the cases where it is possible, concrete
>  suggestions on how the request can be modified so as to become
>  acceptable should be provided.
>
>Given that the Type Code Allocation was DENIED by the Expert, the
>document cannot be published until the issues addressed in the review
>are corrected.
>
>The document therefore cannot be published because of an IANA
>considerations problem, not because of EAP WG review (which did not
>occur).
>
> 
>

-------- Original Message --------
Subject: Re: draft-bersani-eap-psk (Experimental)
Date: Tue, 18 Oct 2005 13:53:18 +0200
From: Mark Townsley
To: Jari Arkko
CC: Bernard Aboba , Margaret Wasserman
References: <432D9713.2000101@cisco.com> <432DB10B.9010408@piuha.net>  <432E61A8.9000606@piuha.net>


Jari, Bernard,

I need to do something with this draft. Are the authors still working on
it? I'd rather progress it or kill it, I don't like limbo.

Margaret, we agreed to shepherd this via EAP WG review back in July
rather than via the RFC Editor. The review is now effectively saying DNP
at this point. Do we even have a DNP process for a document we have
agreed to shepherd?

Thanks,

- Mark


Jari Arkko wrote:

> Yes, that too. My recommendation is to not
> progress this unless the authors come
> back and insist on it (we still have to publish
> if the authors want it and the informational
> RFC requirements are met). It would serve
> the community better if the issues were resolved
> and perhaps even some drafts taken to
> standards track RFCs.
>
> --Jari
>

Email from Jari suggesting not to progress this document unless authors insist


-------- Original Message --------
Subject: Re: draft-bersani-eap-psk (Experimental)
Date: Mon, 19 Sep 2005 09:58:48 +0300
From: Jari Arkko
To: Bernard Aboba
CC: Mark Townsley , Margaret Wasserman
References: <432D9713.2000101@cisco.com> <432DB10B.9010408@piuha.net>


Yes, that too. My recommendation is to not
progress this unless the authors come
back and insist on it (we still have to publish
if the authors want it and the informational
RFC requirements are met). It would serve
the community better if the issues were resolved
and perhaps even some drafts taken to
standards track RFCs.

--Jari

Bernard Aboba wrote:

>Isn't there also discussion ongoing about whether PSK should go under
>IETF change control via the Standards Track or be published now?
>
>On Sun, 18 Sep 2005, Jari Arkko wrote:
>
> 
>
>>We've run an expert review on it (by Jessie Walker). Here's
>>the initial review results:
>>http://mail.frascone.com/pipermail/eap/2005-June/003443.html
>>
>>From what I understand, there were a number of issues,
>>and authors/jesse are still working on to resolve some
>>remaing parts.
>>
>>See also minutes from IETF-63,
>>http://www3.ietf.org/proceedings/05aug/minutes/eap.html
>>
>>--Jari
>>
>>Mark Townsley wrote:
>>
>>   
>>
>>>Chairs,
>>>
>>>The last note I have on this indicates that I am waiting on an EAP WG
>>>review of this document. Has something happened here that I am not aware
>>>of or perhaps dropped the ball on?
>>>
>>>
>>>2005-07-27    08    [public-townsley] [Note]: 'Requested review of this
>>>document from eap-chairs' added by Mark Townsley
>>>
>>>
>>>
>>>Thanks,
>>>
>>>- Mark
>>>
>>>
>>>     
>>>
>
>
> 
>

Security Review minutes from IETF63

http://www3.ietf.org/proceedings/05aug/minutes/eap.html

5. Methods Discussion (40 min)
Goal: Talk about the results of the reviews, make progress

EAP PSK Review (10 min) -- J. Walker
http://www3.ietf.org/proceedings/05aug/IDs/draft-bersani-eap-psk-08.txt

    Independent submission to IESG. Requested EAP method type number. Reviewed by Jesse Walker in June. Update integrating some review points in -08 version. Still number of open issues, e.g. for key derivation. Key naming is not planned, since there is no application like fast reconnect. Discussion will be continued on list.

Hannes: On key control issue: it wouldn't add more complexity to include it here.

Bersani: ok, moving on adding the key control


Jari: The right process for this is to talk about the issues and gather more expert reviews on the list


Hannes: I am one of the authors of PSK, Jesse actually criticized some things he originally proposed so we are a bit confused what he wants.

Security Review from Jesse Walker

[eap] methods and expert reviews
Walker, Jesse jesse.walker@intel.com
Sat, 11 Jun 2005 06:13:10 -0700

    * Previous message: [eap] draft-nakhjiri-eap-ho-00.txt
    * Next message: [eap] methods and expert reviews
    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Jari,

My security review of EAP-PSK is below.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

EAP Type Code Allocation Review Template: EAP-PSK

As noted in RFC 3748, for EAP methods to obtain a Type Code, Expert
Review with Specification is required.  The following list of issues is
provided as a guideline to potential expert reviewers and method
authors. =20

1. Does the method document its security properties in sufficient
manner, as required by Section 7.2 of RFC 3748?

1a. Mechanism. Is the mechanism explained?
>> YES

1b. Security claims. Are the claimed and not claimed properties listed?
>> YES

1c. Justifications for the claims? Is an explanation or reference
provided to each of the claims?
>> YES, the claims are justified. However, below I note several claims
that are false and whose justification therefore should be updated.

1d. Key strength. Is the key strength documented?
>> YES, but more discussion is required. See detailed comments below.

1e. Description of key hierarchy. Is the key hierarchy documented?
>> YES

[Optional, at least for now: does it conform to EAP keying framework?]:
>> YES

1f. Indication of vulnerabilities. Are the known vulnerabilities
documented?
>> NO. There are undocumented vulnerabilities.

[Note: it seems unreasonable to require the documentation of unknown
vulnerabilities :-) The "known" may of course be "known to reviewer" or
"known to author" or "known to the community", but that appears to be
best we can do.]

2. Compliance with EAP packet formats

2a. Does the method comply with the packet formats defined in Section 4
of RFC 3748?
>> YES

3. Compliance with EAP behaviour

3a. Does the method comply with Success/Failure usage as defined in
Sections 2, 2.2, and 4.2?
>> YES

3b. Does the method comply with sequence usage as defined in Section 2.1
of RFC 3748?
>> YES

3c. Does the method comply with request/response processing rules as
defined in Section 4.1 of RFC 3748?
>> YES

3d. Does the method comply with retransmission rules as defined in
Section 4.3 of RFC 3748?
>> Retransmission does not appear to be discussed adequately. The
document needs further work here.

3e. Does the method comply with the usage defined for Identity, as
defined in Section 5.1 of RFC 3748?
>> YES

3f. Does the method comply with the usage defined for Notification, as
defined in Section 5.2 of RFC 3748?
>> The document fails to describe its use of notification. This
oversight should be corrected.

3g. Does the method comply with the usage defined for Nak and
Expanded-Nak as defined in Section 5.3 of RFC 3748?
>> The document fails to describe its use of Nak and Expanded-Nak. This
should be corrected.

3h. Does the method comply with the MIC usage requirements from Sections
3.1, 7.5, and 7.8 of RFC 3748?
>> YES

4. Compliance with IANA requirements

4a. Does the method comply with EAP-based IANA requirements defined in
Section 6 of RFC 3748? That is, if it requests the allocation of new
numbers in the EAP namespace [not applicable if the numbers have already
been allocated], is the type of the document and process appropriate for
the desired action?
>> YES

4b. Does the method comply with other IANA requirements in the IETF
standards track RFCs? For instance, does the method attempt to allocate
TLS extensions (which would only be possible for standards track RFCs)?
>> YES; it complies with IANA requirements for standards track documents


Detailed comments

This is a wonderfully written document, a joy to read, bristling with
beautiful ideas, and addressing an urgent problem. The document has
issues, identified below, that should be addressed before it progresses.
Included in the review are some suggestions for how the issues might be
addressed, but the authors and the working group can certainly
constructively formulate other solutions instead.

The issues identified fall into the following categories:

1. AKA and KDK issues,
2. TEK, MSK, and EMSK issues,
3. Protocol issues,
4. Retries, Replays, and Failures
5. Security bounds, and
6. Odds and ends.

1. AKA and KDK issues

The text should point out more explicitly that AK and KDK are static
long-lived keys, i.e., not session oriented.

The key naming should be made explicit, as the key names used are a
fundamental aspect of this protocol. The usage in the text assumes the
EAP peer name for this key pair is , and it assumes
EAP server name for this key pair is . Including
EAP-PSK as part of the key identifier is critical, as the protocol
design assumes AK and KDK are never used outside of EAP-PSK.

To help us understand the implications of this, it is useful to spell
out the details of any algorithm in pseudo-code. In this case, the
resulting text for this instance of "modified counter mode" used for the
derivation would look something like:

IV :=3D 00000000000000000000000000000000=20
T1 :=3D AES-128-Encrypt(PSK, IV)
T2 :=3D T1 XOR 00000000000000000000000000000001
AK :=3D AES-128-Encrypt(PSK, T2)
T2 :=3D T1 XOR 00000000000000000000000000000002
KDK :=3D AES-128-Encrypt(PSK, T2)
Securely delete T1 and T2
if forward secrecy is required, delete PSK securely
Identify  by the identifier , where id is
the name of the other party

Here AES-128-Encrypt(.,.) means to encrypt its second argument using the
first argument the encryption key, and ":=3D" denotes assignment. The IV
and counter values are expressed in hex.

The identification step at the end is not a nice frill; it is central to
the protocol design and should be made explicit. The reason is the
configured id receives its meaning as the distinguisher of this key pair
by being placed in the context of EAP-PSK. This context and
name then distinguishes this key pair from all other keys in all other
contexts. The security claims made in the specification depend on this
being true.

Note also that the PSK is deleted whenever forward secrecy is required.
Deleting the PSK SHOULD be a SHOULD and the default action.

Since none of these derived keys depend on either the EAP peer or server
NAI, these identities must get bound to the keys in some other way.
However, there is no protocol defined to bind the identities to the
derived AK or the KDK, implying that a different and independent PSK
must be configured between each  pair. This is a usability
issue. In particular, the derivation for AK and KDK does not lead to
different keys if the administrator spreads the same PSK across multiple
devices. The reality is that many administrative domains will configure
the same PSK on each and every device, while all the security claims of
the protocol assume that different keys are configured between each pair
of devices. Including the NAIs for the EAP peer and server in the
derivation of the AK and KDK would afford an increase in security in the
normal case by separating the  pairs between different devices
in every case, and by explicitly binding the identities to these keys.
It would also indirectly bind the identities to the TEK, MSK, and EMSK.

There is a second problem with the  derivation, in that it is
subject to prefix attacks. This is not a problem in the overall protocol
design, but you never know when implementations will have bugs that
might allow an attacker to somehow exploit this kind of weakness. The
derivation should take into account the number of bits derived, and
derive different keys if the same information is presented to the
algorithm using the same parameters otherwise.

So are there any plausible ways to include the NAIs and the derived key
lengths into the derivation without discarding the entire key derivation
procedure? Let us try to suggest some.

The most obvious thing to try is to somehow use AES to "hash" the
identities and then use this "hashed" value as the initialization vector
IV presented to modified counter mode, instead of the IV
00000000000000000000000000000000. We want to use AES for this in order
to preserve the lovely property that AES encrypt is the only
cryptographic primitive required by the design.

A procedure for constructing such an IV would start by concatenating the
identities and padding them with the derived key length in some
well-defined manner, e.g.,

L :=3D length(ID_S) + length(ID_P)
M :=3D ID_S || 0x00 || ID_P || 0^(128 - (L + 17) mod 128) || 0x100

Here "length(.)" gives the length of its argument "." in bits, "ID_S" is
the identity of the EAP server, "ID_P" the identity of the EAP peer,
"||" means concatenation, and a^b means to concatenate b copies of bit
a. This makes the concatenated string a multiple of 128 bits. The magic
number "0x100" is the number of bits derived (256), represented as a hex
value. The magic number 17 is the number of bits required to encode
0x100 and the "0x00" sitting between ID_S and ID_P. The 0x00 is inserted
between ID_S and ID_P to prevent sliding window attacks, but this
presupposes that 0x00 is not a valid character in an NAI.=20

By encoding the number of derived bits into the string to be hashed, we
can defeat the prefix attack problem if we can find a collision
resistant hashing scheme. So such a scheme will be the next thing to
search for. Two plausible AES-based hashing schemes immediately come to
mind for producing IV from M.

The first is to try to use AES in CBC-MAC mode, but for that we need a
key; one idea for a key is the PSK:

IV :=3D AES-128-CBC-MAC(PSK, M)

This is not ideal, however, because PSK would be used in two different
ways --once for hashing and a second time for key derivation--and
multiple usages of a single key is almost always a bad idea. While reuse
in this case may appear benign on first glance, why should we bother
with an approach that will require a tricky analysis to confirm that it
is indeed safe? A variant would be to use some "well-known" key as the
CBC-MAC key, although this key would always be block cipher dependent:

K :=3D 00000000000000000000000000000000 (* AES dependent key! *)
IV :=3D AES-128-CBC-MAC(K, M)

In either case, the "hashing" scheme relies on the assumption that a
block cipher in CBC-MAC mode is a pseudo-random function, so the
resulting output should be collision resistant for each pair of
identities and length (at least if we construct M properly). If you
prefer, use OMAC1 mode instead of CBC-MAC. Relying on CBC-MAC for
hashing is an egregious but probably effective hack.

A second way to compute IV might be to Davies-Meyer hash M under
AES-128:

Partition M =3D M1 M2 ... Mn into 128 bit blocks
H :=3D 00000000000000000000000000000000
for i =3D 1 to n do
H :=3D AES-128-Encrypt(Mi, H) XOR H
IV :=3D H

This is a genuine hashing algorithm. The Davies-Meyer construction is
collision resistant when the block cipher behaves like a pseudo-random
permutation, so again including the length in the hashed IV solves the
prefix attack problem. This construction also relies only on public
information; there is no key required as with the CBC-MAC approach. The
major problem with this is Davies-Meyer requires n AES key schedule
initializations, one for each block Mi. However, since the derivation
for AK and KDK occurs "once," this overhead should be insignificant.

Other approaches to computing IV may also be worth considering. Which
one to=20
choose will probably depend on the outcome of the discussion we have
below for the TEK/MSK/EMSK derivation. And if the CBC-MAC construction
is used, then we will need some methodology to select the well-known key
K.

In any event, to summarize, using a hashed value of the derived bit
length and identities instead of the zero IV would improve the design in
three ways:

a. It directly binds the identities of the server and peer to AK and to
KDK, and indirectly binds these to any TEK, MSK, or EMSK derived from
these.

b. It improves the usability of the entire design by forcing AK and KDK
to be unique and cryptographically separated for each pair of distinct
identities, even when the same PSK is configured on all devices within
an administrative domain.

c. It defeats prefix attacks.

Finally, in a totally different direction, perhaps it would be
worthwhile to give some thought to key roll-over for the long-lived
keys--no key can ever be eternal when security is an issue. It might be
better to bind the key pair  to a triplet that included some
sort of PSK generation number, e.g., . Here
psk-instance could be a date-timestamp or a sequence number or any other
generation marker. If you do this, the text should give some
consideration to how the key instance is conveyed by the protocol and
perhaps in the key derivation as well.

2. TEK, MSK, and EMSK issues

The derivation of the TEK, MSK, and EMSK depend on only RAND_S and KDK.
This means the peer assumes (i.e., "trusts") that the server generates a
statistically unique RAND_S for each session. If the server fails to
generate a statistically unique RAND_S, then the TEK, MSK, and EMSK are
compromised on each repeated session.

To understand the implications of this, again it is useful to spell out
pseudo-code for the key derivation:

T1 :=3D AES-128-Encrypt(KDK, RB)
for ci =3D 1 to 9 do
T2 :=3D T1 XOR ci
SK[ci] :=3D AES-128-Encrypt(KDK, T2)
Securely delete T1 and T2
TEK :=3D SK[1]
MSK :=3D SK[2..5]
EMSK :=3D SK[6..9]
Securely delete SK

Here, the pseudo-code treats assumes ci is represented as a 128 bit
integer in network byte order.

Since the length is not included in the key derivation, prefix attacks
are again possible against the key derivation algorithm itself, even if
this is not a concern within the overall design.

Returning to the trust assumption, the peer has to assume that the
server will generate a different RAND_S on every instance of the
protocol. We will see in the protocol analysis this is not a good
assumption--replay attacks are feasible against the peer--and indeed, it
is unnecessary. It is almost always a good idea to remove unnecessary
assumptions when we can. We could perhaps remove the trust assumption
about RAND_S by again hashing together RAND_S and RAND_P to obtain the
RB value to use, e.g.:

RB :=3D AES-128-CBC-MAC(0^128, RAND_S || RAND_P || 0^117 || 0x480)

using the CBC-MAC hashing method with a 0 key, or

H :=3D 00000000000000000000000000000000
H :=3D AES-Encrypt-128(RAND_P, H) XOR H
H :=3D AES-Encrypt-128(RAND_S, H) XOR H
RB :=3D AES-Encrypt-128(0^117 || 0x480, H) XOR H

using Davies-Meyer hashing. Here 0x480 =3D 1152 is the number of bits
derived, which is encoded in 11 bits, leaving 0^117 =3D 117 bits of =
zeros
needed to complete the padding block. Note we do not need any padding
between RAND_S and RAND_P to protect against sliding window attacks,
because both are fixed length. If this RB value is used as the input for
the TEK/MSK/EMSK derivation, then both parties can assure themselves
that the session key is fresh by contributing their own statistically
unique input, and the inclusion of the length defeats prefix attacks.
This construction could also be used to address one of the security
flaws in the present definition of the protocol message flows, discussed
below.

This is a case where the choice between CBC-MAC and Davies-Meyer hashing
probably matters. The CBC-MAC approach requires only a single key
schedule initialization (perhaps per device reboot), while the
Davies-Meyer approach requires three (for each protocol instance). Since
the session key derivation occurs once at the start each instance of the
protocol, the CBC-MAC construction might therefore be preferable, even
though it is a hack.

3. Protocol issues

The message flow tries to "optimize" away "unnecessary" parts of the
AKEP2 protocol. This does not work, because the Bellare-Rogaway
construction is optimal and cannot be further optimized in any
fundamental way without degrading its security. There are at least three
problems in the present design: (a) message 2 fails to include ID_S, (b)
message 3 fails to include ID_S and RAND_P, and (c) it is not evident
that message 4 is protected from forgery.=20

Point (a). Since message 2 does not repeat ID_S, the peer never attests
that it agrees ID_S is the server's identity. This problem cannot be
fixed by replacing ID_P with ID_S in message 2, because then the peer
would have no vehicle to attest to its own identity and hence identify
the correct AK to use.

The omission of ID_S is a symptom of a deeper problem. Since this
construction does not include both ID_S and ID_P, man-in-the-middle
attack becomes possible. In this particular case, the server has no way
of knowing whether the identity ID_S was delivered to the peer. In the
present design a malicious node M could replace ID_S with ID_M, and the
peer will authenticate with the wrong party M instead of the server. At
least one authenticated message must MAC both identities, or the key
used for the MAC can be replaced by the man-in-the-middle. This must be
fixed.

I expect the message 2 format was drawn the way it is to prevent
fragmentation. However, since there is no way to defend against
man-in-the-middle attacks without MACing both identities, the spec will
have to do so, or it will have to further limit the maximum combined
lengths of ID_S and ID_P, or it will have to find one way to compress
some of the fields, or we will have to accept man-in-the-middle attacks.

ID_S could be replaced in message 2 by some hashed representation of
ID_S, such as AES-128-CBC-MAC(0^128, ID_S || 0^(length(ID_S) +
length(length(ID_S)) mod 128 || length (ID_S)). This "extra" crypto is
unattractive on low power devices. The question becomes would you rather
spend the extra MIPS or increase the bandwidth consumed by inserting
ID_S into message 2 or be subject to man-in-the-middle attacks?
Resolving this issue is the only hard choice I can see that is needed to
completing the document.

Point (b). The peer P never learns whether messages 1 and 3 are live,
because the protocol does not force the server to MAC the peer's
challenge RAND_P. This problem allows a malicious entity M to replay an
old message 1 and 3 to convince the peer to think it has authenticated
with the server. And the message needs to include ID_S instead of ID_P,
because the server has never had the opportunity to attest to its own
identity, i.e., to the correct AK to use; remember message 1 and its
ID_S value could have been a forgery. The missing ID problem can be
fixed by including ID_S instead of ID_P in message 3. The missing RAND_P
problem again can be fixed either by including it directly in message 3
or by including it in the derivation of AK. Since the latter is not
possible, message 3 has to somehow include RAND_P.

One way to accomplish this without changing the message 3 format is to
replace RAND_S in message 3 with hashed RB value suggested above; recall
that we proposed "hashing" RAND_S and RAND_P together to form RB. Since
such an RB includes RAND_P, the peer will receive assurance that the
message is indeed fresh when RB is MACed. And RB makes for a perfectly
good instance (i.e., session) identifier. This would be especially
beneficial to protect exchanges protected by the TEK in message 4 and
beyond. If this direction is taken, then we would NOT want to use the
KDK for RB derivation, because it is then explicitly a public value, not
a key; we would want to use either Davies-Meyer hashing or CBC-MAC
hashing based on a well-known key.

The alternative, of course, is to explicitly include RAND_P in message
3, as done by the Bellare-Rogaway construction.

Point (c). Neither Figure 3 nor the accompanying text spells out
explicitly how message 4 is protected. Message 4 could be protected by
either the AK (and an OMAC1) or by the TEK (used with EAX). In the
latter case, we need to know which bits are encrypted and which merely
forgery protected. To accomplish this end, the text could, for instance,
in Figure 8 use notation like {...}* to indicate EAX encryption under
the TEK; the rest of the message would be EAX authenticated. The session
identifier--whether RAND_S or the derived RB above--should remain in the
clear but be integrity protected.=20

Since we would want to leave part of the P_CHANNEL_P_1 data structure in
the clear (e.g., the sequence number) and a notation for accomplishing
this is awkward, this suggests that we have not yet found the right
boundary between the P_CHANNEL data structure and its underlying
transport.

There is another problem with message 3: P_CHANNEL_P_1 is not protected
by the MAC. Depending on what happens otherwise with the protocol
definition, this could enable cut-and-paste attacks against the message.

3. Retries, Replays, and Errors

It will be necessary somewhere to specify how to handle retransmissions,
i.e., we need a standardized treatment of "retries" as distinct from
"replays". This holds for both the messages in the base protocol, and
extended messages protected by the nonce N. Retries should cause the
receiver to retransmit, while replays should be discarded. The
difference between the two will always be an arbitrary distinction, but
is needed for interoperability's sake.

The document uses sequence numbers for the extended portion of the
protocol, but fails to indicate the sequence spaces associated with
each, how they are initialized, and how they are used to detect replays.
I believe that there needs to be different sequence spaces for each of
the two logical half-duplex channels, but perhaps the request/response
nature of EAP will save us from this fate.

The protocol seems to protect itself from reflection attacks by
including the EAP header in the MAC. This is a detail the text glosses
over and needs to be made explicit, especially in extended
authentication protection provided by EAX, as it will likely be missed
by many implementers.

One notable omission from the spec is failure processing. As an example,
what does the server do if it receives a message 2 for a protocol
instance that it has not initiated? Experience shows that different
implementers will handle such messages in different ways, almost always
to the detriment of interoperability.

4. Security Bounds

Page 39, Section 6.5 asserts that EAP-PSK is not subject to dictionary
attack. This is not true when the PSK is computed from a feasibly
searched key space, e.g., when it is, or is derived from, a password.
Suppose, for instance, that the 802.11i password-to-key mapping is used
to establish a PSK. The attacker can invoke this mapping on each
dictionary entry, derive the AK, and use each value to simulate an
authentication exchange. The attacker has only to compare the results of
a recorded EAP-PSK instance with each simulated exchange computed using
a key from the dictionary. The attacker can do the same with any other
exposed key. Thus, none of the derived keys has any more strength than
the original password. The specification should make this clear.
Conversely, however, all of the derived keys are immune to dictionary
attacks if PSK is. For the remainder of this section we will assume the
PSK is taken from an infeasibly searched key space, so that dictionary
attack is not possible.

When AES is used in any CBC-MAC-like mode, the key should be replaced
after 2^48 blocks have been processed. Since EAP-PSK protects at most 4
OMAC1-protected messages for each protocol instance, and since each
message is at most about 1024 octets =3D 2^6 blocks, this means that AK
should be replaced after about 2^40 instances. This bound could be
improved, but why bother? There are about 2^35 milliseconds per year, so
this permits about 2^5 years worth of protocols instances if new
instances are initiated once per millisecond.

Estimating the security of the KDK is tricky. The modified counter mode
scheme is similar enough to the parallel key generation scheme in [1]
that we should be able to derive bounds using an argument modeled on
theirs, but I have not tried to push this through. The alternative taken
here is to make a back-of-the-envelope estimate of the distribution of
the derived keys directly. If the RB passed as input into the
TEK/MSK/EMSK derivation is uniformly distributed, and if we were
deriving only one block, then we expect a significant chance of RB's
repetition after 2^64 invocations. Each protocol instance, however,
derives a swath of 9 consecutive blocks from the KDK, so the probability
of hitting any particular block again with a new randomly selected RB
and its children is 9/2^128 < 1/2^124. We should therefore expect a
significant probability collisions of RB to result in collisions of
counter mode blocks after about 2^62 invocations. If we limit the total
number of protocol instances to 2^40 or so, then it appears the design
has a safety margin for all of the derived session keys to be unique.

The text exhibits some confusion about how to measure the EAX key
strength. It is not the number of messages but rather the total number
of encrypted and integrity protected blocks that has to be limited. The
probability that an attacker can successfully attack the EAX encryption
scheme after q blocks have been encrypted is bounded by 9*q^2/2^128. The
probability that an attacker can produce a successful forgery after q
blocks have been integrity protected is bounded by (10*q^2 + 1)/2^128.
The EAX proof of security says that these bounds are tight, i.e., that
no attacker can do any better than this if AES is secure. If the
protocol spec were to bound q at, say, 2^46, then we would have
confidence that an adversary would never have more than about a
9*(2^46)^2/2^128 =3D 9*2^92/2^128 =3D 9/2^36 < 1/2^32 chance of somehow
breaking the encryption, and no more than a 10*(2^46)^2 + 1)/2^128 <
10*2^93/2^128 < 1/2^31 to successfully create a forgery, assuming AES is
a secure block cipher. That is, if we were to limit the total amount of
data protected under the TEK to 2^46 blocks, then we would have great
confidence that the protocol will not expose protected data. While the
number of encrypted blocks will be smaller than the number of integrity
protected blocks, this limit should never become a problem in practice.

Estimating the number of the MSKs and EMSKs that can be safely derived
depends on how they are used; the techniques in [1] are appropriate for
doing this. It is sufficient to say that EAP-PSK appears as robust in
this dimension as any other EAP method.

5. Odds and Ends

Here are a number of miscellaneous comments:

It would be worth considering replacing OMAC1 by CMAC. NIST SP800-38B
[2] defines CMAC as the "approved" CBC-MAC variant.

Page 5, Section 1.1.1, and Page 43, Section 6.9: While the protocol does
not offer PFS, it does offer forward secrecy if the PSK is securely
deleted after the AK and KDK are derived and if the PSK is not taken
from a feasibly searched key space. This would be worth noting.

Page 17: What specific security claim is being made by the phrase "proof
of security"? Please detail the security model and assumptions used, and
also the specific claims being made based on these. The proof may or may
not be relevant in the present context.

Page 21: The design requires the EAP server to expose its identity and
to use the same identity with each peer, unless there is something in
the EAP-Response/Identity triggering the method that tells it otherwise.
This is a subtle configuration constraint that may not be evident to
administrators deploying the protocol.

Page 23, Figure 9: The hashed RB value constructed above that
incorporates both RAND_S and RAND_P seems like a better session
identifier than the RAND_S in messages 3 through 2i+1, because it is
computationally infeasible for either party to force it to a value used
by a prior protocol instance. Beginning in message 4, the P_CHANNEL_P_k
needs to be protected by EAX using the TEK.

Page 25, Flags field: The figure of the Flags field needs to be cleaned
up. It should be relabled to have only 8 bits, not 9. And the unreserved
field should be widened from 1 to 2 bits.

Page 35: What happens if the tunneled method fragments?=09

Page 38, Section 6.1: Until message 2 is fixed to include both ID_S and
ID_P, EAP-PSK does not provide mutual authentication.

Page 38, Section 6.2: The assertion that the R field is protected does
not yet appear warranted, given that the sequence spaces have not yet
been completely specified, so replay and perhaps reflection attacks
appear to be possible, and further given that the message 1 and 3
constructions allow an attacker to replay old EAP-PSK messages. The
existing text would become correct when these issues are addressed.

Page 42, Section 6.7: Since message 1 is unprotected, it can be forged
by an adversary. Once it chooses to initiate an EAP_PSK instance, the
server must commit to a value RAND_S to enable the peer to recover from
a denial-of-service attack based on flooding forged message 1s. This is
a reasonable constraint to put on server implementations. It will
require you to fill out the missing discussion on the difference between
retries and replays. RAND_S remains constant across retries, but is
changed on all protocols instances the server classifies as "new". The
receiver should retransmit the last message if it receives a duplicate
within some retry message, and declare a duplicate a replay otherwise.

Page 43, Section 6.8: Actually session independence comes about by
choosing non-repeating instance identifiers . The current protocol lacks this property due to its inability
to protect against replayed messages 1 and 3. When this is fixed, the
protocol will have session independence.

Page 43, Section 6.9. The protocol design explicitly assumes that
neither AK nor KDK are shared beyond the two parties utilizing them. AK
loses its efficacy to mutual authenticate the peer and server with each
other when it is shared. Similarly, the derived TEK, MSK, and EMSK lose
their value for authentication when KDK is shared with a third party.

Page 43, Section 6.12: It should be easy to add a "fast reconnect" if
the server and peer maintain the TEK and their replay counters. Whether
this is valuable is dubious, however.

Page 46, Section 6.16. I think it is a mistake to not define a
cryptographic binding mechanism of a key producing inner method and
EAP-PSK. It is easy to do, and it makes EAP-PSK safe to use key deriving
inner methods. Subsidiary methods are becoming more important, as IT
departments are moving to evaluation of the patch level of devices
before they allow data to pass.


References:

[1] M. Abdalla and M. Bellare, "Increasing the lifetime of a Key: A
Comparative Analysis of the Security of Re-Keying Techniques", ASIACRYPT
2000

[2] M. Dworkin (NIST), SP800-38C, "Recommendation for Block Cipher Modes
of Operation: The CMAC Mode for Authentication", May 2005



    * Previous message: [eap] draft-nakhjiri-eap-ho-00.txt
    * Next message: [eap] methods and expert reviews
    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]