Subject: RE: [Emu] EMU PSK Method work Item

From: "Salowey, Joe" <[email-masked]>
Date: Thu, 2 Feb 2006 11:40:38 -0800

The security requirements in 4017 are not comprehensive, however I don't
think the security requirements for PSK need to be comprehensive.  I
would rather not open up the list of requirements for PSK too broadly. I
believe 4017 and 3748 provide a decent set and expanding them would
probably run against the goals of "compact" and "simple".  If there are
additional requirements that are not in 4017 or 3748 that are needed in
the PSK mechanism then we need to bring these out now so the design team
can consider them.  

I think the investigation of requirements of for various future and
current usages of EAP methods is good, but I think this will be an
ongoing process and a full analyisis is not necessary to complete the
PSK method work.  

> -----Original Message-----
> From: Thomas Otto [mailto:[email-masked]] 
> Sent: Wednesday, February 01, 2006 1:09 PM
> To: [email-masked]
> Subject: Re: [Emu] EMU PSK Method work Item
> 
> Am Mittwoch, 1. Februar 2006 17:01 schrieb Hao Zhou (hzhou):
> 
> > I wonder whether we should look at the strong shared secret method
> > alone. It seems we might achieve this goal and the two 
> other work group
> > items, TLS-based EAP method and existing password database support,
> > using a single EAP method, e.g., a TLS based EAP method 
> supporting PSK.
> > This would save us the work of trying to define two or three EAP
> > methods. One thing might help us is to define what exactly 
> is "strong
> > shared secret", "compact", and "simple" in a requirement or problem
> > statement. They might be expressed in turns of desired number of
> > exchanges, computing power, cipher suites limitations, etc. 
> The security
> > requriements are already addressed by RFC 4017. 
> 
> I do not think that the security requirements of RFC 4017 are 
> comprehensive.
> We should re-think about the requirements. What about, for instance, 
> 
> * strong identity protection?
> * denial-of-service resistance?
> * non-repudiation?
> 
> They are not covered by RFC 4017, but seem to be worth to be 
> taken into
> account.
> 
> My advise is to define a requirement catalogue apart from RFC 4017.
> Therefore, the current EAP deployments should be analyzed 
> (e.g. EAP is used
> in 802.11, 802.16, IKEv2, TLS, 3G networks...) and the specific 
> characteristics of these environments elaborated. Second, 
> intended / future 
> application scenarios should be taken into account (mesh 
> networks, p2p, ...). 
> 
> And: We should define a metric, that is, each requirement 
> should get a weight
> factor. One example: The assertion: "avoid TLS and public key 
> cryptography
> with regard to shared secret methods, because public key 
> cryptography is 
> too expensive. 
> There are a lot of ways to make TLS lightweight, e.g. by 
> exploting the session
> resumption mode, or by using pre-shared key ciphersuites, or 
> by variing  the 
> cryptographic key strength (e.g. do we really need 3072-modp 
> DH or does it
> suffice to take 2048 bit group).  To answer 
> cryptographic-related functions, 
> cryptographicexperts should be asked for their advise.
> So, the argument to avoid public key cryptography is weak and 
> must be refined.
> Next to the categorization of mandatory, recommended and 
> optional, one might
> refine the value of the security requirement by a weight factor.
> 
> That's for now, bottom line and start point for further 
> discussions: RFC 4017
> is not comprehensive.
> 
> Thomas
> 
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/emu
> 

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

---

From: Sam Hartman <[email-masked]>
Date: Sat, 04 Feb 2006 14:41:51 -0500

>>>>> "Salowey," == Salowey, Joe <[email-masked]> writes:

    Salowey,> The security requirements in 4017 are not comprehensive,
    Salowey,> however I don't think the security requirements for PSK
    Salowey,> need to be comprehensive.  I would rather not open up
    Salowey,> the list of requirements for PSK too broadly. I believe
    Salowey,> 4017 and 3748 provide a decent set and expanding them
    Salowey,> would probably run against the goals of "compact" and
    Salowey,> "simple".  If there are additional requirements that are
    Salowey,> not in 4017 or 3748 that are needed in the PSK mechanism
    Salowey,> then we need to bring these out now so the design team
    Salowey,> can consider them.

    Salowey,> I think the investigation of requirements of for various
    Salowey,> future and current usages of EAP methods is good, but I
    Salowey,> think this will be an ongoing process and a full
    Salowey,> analyisis is not necessary to complete the PSK method
    Salowey,> work.

Also, keep in mind that general requirement investigation is outside
the charter of this working group.  This working group is specifically
chartered to meet requirements outlined in RFC 3748 and 4017.

Avoiding getting side tracked in a long requirements phase is
important if this group is going to be efficient and meet needs for
standards-track EAP mechanisms.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 07 Feb 2006 15:34:58 +0200

>ongoing process and a full analyisis is not necessary to complete the
I am also afraid of a lengthy requirements collection phase.
Focusing on an existing and practical use case is possible
via RFC 4017. We should do that.

--Jari

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 17 Feb 2006 09:43:44 -0800

We've made an initial start on RFC 2716bis which should be showing up on the 
archive soon:
http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-00.txt

This first draft mostly focusses on cleaning up "PPP"isms, updating 
references and examples, etc.

Next step is to identify EAP TLS implementations and interoperability issues 
encountered in bakeoffs and in customer deployments.  So if you have 
implemented EAP TLS and encountered some problems, or if there are sections 
that didn't make sense to you, it would be helpful to post these to the 
list, along with text changes that might clarify the problem.

The biggest issue that has come up in emails I have received over the years 
relates to certificate usage.   I am curious what people think we should be 
doing in the document in this regard.  For example, I'm curious as to 
whether any of the EAP-TLS implementers are also planning to implement RFC 
4334, and if not, whether there might be some interoperability impact on 
your existing implementation.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 23 Feb 2006 14:34:50 +0200

Looks great, thank you Bernard!

Here's a diff between the RFC and your draft for everyone's
viewing pleasure:

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://www.ietf.org/rfc/rfc2716.txt&url2=http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-00.txt

A couple of quick comments:

>5.  Security Considerations
>
This needs more work, to fill in the descriptions
required by RFC 3748.

>   However, in the case where the peer is initiating an intial PPP
>
s/intial/initial/

>[RFC2246] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC
>          2246, November 1998.
>
Refer to 2246bis instead, as it is already in the RFC editor's queue.
But I don't follow TLS WG, I hope there isn't some kind of a
hash negotiation change waiting to happen for 2246bis...

>[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
>          Considerations Section in RFCs", BCP 26, RFC 2434, October
>          1998.
>
This isn't referred to from anywhere.

>[DES]     National Bureau of Standards, "DES Modes of Operation", FIPS
>          PUB 81 (December 1980).
>  
>
Or this [sigh of relief].

--Jari

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 24 Feb 2006 15:21:37 -0800

>This needs more work, to fill in the descriptions required by RFC 3748.

Right.  Here are the claims that I think can be made:

      Auth. mechanism:           Certifications
      Ciphersuite negotiation:   Yes
      Mutual authentication:     Yes
      Integrity protection:      Yes
      Replay protection:         Yes
      Confidentiality:           Depends
      Key derivation:            Yes
      Key strength:              (depends on ciphersuite negotiated)
      Dictionary attack prot.:   Yes
      Fast reconnect:            Yes
      Crypt. binding:            N/A
      Session independence:      Yes
      Fragmentation:             Yes
      Channel binding:           No

Most EAP-TLS implementations do not support Privacy, since they send the 
client cert in the clear.  However, in theory privacy support is possible if 
the implementation brings up a protected channel based on server 
authentication, then requests the client cert.  I'm curious if any existing 
implementations support TLS privacy.

In terms of key strength, this depends on the size of the public/private key 
pairs used in the certificate.     As noted in [RFC3766] Section 5, the 
level of attack resistance in bits is related to the
RSA or DH module and DSA subgroup size in bits:

       Attack Resistance  RSA or DH Modulus     DSA subgroup
          (bits)              size (bits)                      size (bits)
        -----------------     -----------------                 ------------
        70                          947                        128
        80                        1228                        145
        90                        1553                        153
        100                       1926                       184
        150                       4575                       279
        200                       8719                       373
        250                     14596                       475

So a 2048-bit RSA key is required to provide 128-bit equivalent strength.  
Typically the default is lower than this (e.g. 128 bits).

A formal analysis of EAP TLS has been done, that I am hoping we can refer to 
for some of the properties:

http://theory.stanford.edu/~changhua/f15-he.pdf
http://www.cis.upenn.edu/~spyce/may05/anupam.pdf

>From my reading of the paper, EAP-TLS is proven secure when utilized with 
802.11, as long as the TLS certificates are not reused for another purpose 
(e.g. private keys are  not shared or same cert used for both EAP and a Web 
server).   This raises some questions about whether certificates used for 
EAP TLS should be restricted, as proposed in this specification:

http://www.watersprings.org/pub/rfc/rfc4334.txt

However, as far as I know, RFC 4334 has not been implemented.

BTW, the major non-editorial changes from RFC 2716bis are the removal of 
several paragraphs:

RFC 2716, Section 3.4:

   Note that since the peer has made a claim of identity in the EAP-
   Response/Identity (MyID) packet, the EAP server SHOULD verify that
   the claimed identity corresponds to the certificate presented by the
   peer.  Typically this will be accomplished either by placing the
   userId within the peer certificate, or by providing a mapping between
   the peer certificate and the userId using a directory service.

Since RFC 3748 indicates that the EAP-Response/Identity is for routing and 
that it need not match the method-specific identities, this paragraph is not 
appropriate.

RFC 2716, Section 3.6:

   In order to ensure agreement between the EAP-TLS ciphersuite
    negotiation and the subsequent ECP negotiation (described in [6]),
    during ECP negotiation the PPP peer MUST offer only the ciphersuite
    negotiated inEAP-TLS.  This ensures that the PPP authenticator MUST
    accept the EAP-TLS negotiated ciphersuite in order for the
    onversation to proceed.  Should the authenticator not accept the
    EAP-TLS negotiated ciphersuite, then the peer MUST send an LCP
    terminate and disconnect.

    Please note that it cannot be assumed that the PPP authenticator and
    EAP server are located on the same machine or that the authenticator
    understands the EAP-TLS conversation that has passed through it. Thus
    if the peer offers a ciphersuite other than the one negotiated in
    EAP-TLS there is no way for the authenticator to know how to respond
    correctly.

As far as I know, implementations of EAP TLS do not utilize TLS ciphersuite 
negotiation for the purpose of negotiating link layer ciphersuites, since 
this would conflict with link layer ciphersuite negotiation (such as the 
4-way handshake in 11i).

RFC 2716 Section 3.5 (relating to key derivation) needs to be revised to use 
more modern terminology (MSK, EMSK, etc.), but hasn't been done yet.

---

From: Jari Arkko <[email-masked]>
Date: Sat, 25 Feb 2006 07:15:25 +0200

Yes. All of this sounds very reasonable. I was
surprised to learn about the privacy part.

--Jari

Bernard Aboba wrote:

> Most EAP-TLS implementations do not support Privacy, since they send 
> the client cert in the clear.  However, in theory privacy support is 
> possible if the implementation brings up a protected channel based on 
> server authentication, then requests the client cert.  I'm curious if 
> any existing implementations support TLS privacy.
>
> In terms of key strength, this depends on the size of the 
> public/private key pairs used in the certificate.     As noted in 
> [RFC3766] Section 5, the level of attack resistance in bits is related 
> to the
> So a 2048-bit RSA key is required to provide 128-bit equivalent 
> strength.  Typically the default is lower than this (e.g. 128 bits).
>
> A formal analysis of EAP TLS has been done, that I am hoping we can 
> refer to for some of the properties:
>
> 802.11, as long as the TLS certificates are not reused for another 
> purpose (e.g. private keys are  not shared or same cert used for both 
> EAP and a Web server).   This raises some questions about whether 
> certificates used for EAP TLS should be restricted, as proposed in 
> this specification:
>
> BTW, the major non-editorial changes from RFC 2716bis are the removal 
> of several paragraphs:
>
> RFC 2716, Section 3.4:
>
> Since RFC 3748 indicates that the EAP-Response/Identity is for routing 
> and that it need not match the method-specific identities, this 
> paragraph is not appropriate.
>
> RFC 2716, Section 3.6:
>
> As far as I know, implementations of EAP TLS do not utilize TLS 
> ciphersuite negotiation for the purpose of negotiating link layer 
> ciphersuites, since this would conflict with link layer ciphersuite 
> negotiation (such as the 4-way handshake in 11i).
>
> RFC 2716 Section 3.5 (relating to key derivation) needs to be revised 
> to use more modern terminology (MSK, EMSK, etc.), but hasn't been done 
> yet.
>
>
>
>