A Technical Comparison of TTLS and PEAP
Subject:   Clarifications
Date:   2003-04-18 09:44:23
From:   anonymous2
The article was a good start. There are some inaccuracies; and probably things have changed since the article was written.

I didn't see the advantages in TTLS claimed in the article.

This is what I found out which is different than mentioned in the article.

PEAP is authored by Cisco, MS, RSA.
PEAP seems to be available from more vendors than TTLS.
PEAP RADIUS servers are available from Microsoft, Funk, Meetinghouse (Windows and Linux), Cisco, Radiator.
PEAP clients are available on many systems including Win95/98/ME, NT, 2000/XP, Pocket PC 2002.

TTLS supports 3 choices for password authentication(PAP, CHAP, MSCHAPv2) and PEAP supports one (MSCHAPv2). I probably don't need three.

Cisco PEAP supports One-time-passwords. Microsoft PEAP supports passwords; and allows other vendors to provide EAP methods that work inside PEAP. TTLS supports passwords and one-time-passwords.

Microsoft PEAP supports authentication of machines or users. Machine verification seems useful in certain situations.

Full Threads Oldest First

Showing messages 1 through 11 of 11.

  • regarding TTLS : AVP's format
    2004-03-16 22:49:04  useme1 [View]

    Can you people please guide me on how to encapsulate PAP,CHAP,MS-CHAP messages in AVP formats.

    I am a new bee to this EAP-TLS and TTLS.

    Any useful documents or open source for the same would be of great help

    Much Thanks
  • Clarifications
    2003-05-16 14:39:46  anonymous2 [View]

    Hmmm... MSCHAPv2 which requires a database that supports MSCHAPv2 or passwords stored in plain-text. Therefore no authenticating PEAP to LDAP or SQL(unless sql database supports MSCHAPv2). That alone gives the edge to TTLS. There's a free TTLS client for W2k/XP from
    • Clarifications
      2003-06-13 12:48:08  anonymous2 [View]

      The information seems technically incorrect.

      MSCHAP does not require passwords stored in plain-text; and this is considered one of the many advantages of MSCHAP compared to CHAP. CHAP requires the password to be stored in plain-text.

      MSCHAP protocol can be used with SQL. A number of RADIUS servers support PPP-MSCHAP with SQL.

      If there is indeed a real demand for SQL with MSCHAPv2, then it maybe just a question of time before RADIUS vendors support it.
      • MS-Chap is designed for MS Databases
        2003-07-07 08:51:37  anonymous2 [View]

        Here is the issue: When using the MS-CHAP or MS-CHAPv2 protocols, the Challange exchange between the RADIUS server and the supplicant are based on the NT-Hash of the users password. This means that the Database that the RADIUS server looks at needs to have access to the NT-Hash of the users password, not the clear text version of the password. This is fine if your database happens to be Active Directory, because this is how passwords are stored in AD, but if it is LDAP, or SQL, you would have to go through some process to get the NT-hash of all your users passwords into this other database. This is why EAP-MSChapv2 (and thus Micosoft's PEAP supplicant) is really only good if your database is Microsoft.
        • MS-Chap is designed for MS Databases
          2003-07-08 21:59:41  anonymous2 [View]

          Sorry, the information above seems technically incorrect.

          It is trivial to create the hash from the clear text password, and this can be done by the RADIUS server during authentication. SQL databases typically store the password in clear text.
          • MS-Chap is designed for MS Databases
            2003-07-28 16:11:26  anonymous2 [View]

            Actually it is correct, but probably deserves a more detailed explanation.

            >> It is trivial to create the hash from the clear text password, and this can
            >> be done by the RADIUS server during authentication.

            This is correct, but unfortunately in a PEAP(MS-CHAP-V2) exchange, the RADIUS server never receives the clear text password from the user.

            Remember, CHAP, MS-CHAP and MS-CHAP-V2 are all challenge based exchanges, where the server generates a random challenge, and sends it to the supplicant. The supplicant then uses that challenge to hash the userís password, returning the result in a challenge response to the server. The server then uses the same challenge that was sent to the supplicant to hash it's stored version of the password, and it compares it's result with the result returned in the challenge response. If they match, then the user must have supplied the same password that the server retrieved from the database.

            The tricky part is that with MS-CHAP, when the supplicant receives the challenge from the server, it hashes the NT-Hash of the password with the challenge, and returns the NT-HASH-HASH of the password in the challenge response. This means that the server also has to use the NT-Hash of the password as input in order for the results to match.

            Hopefully it makes a bit more sense this time :)
            The bottom line:
            PEAP(MS-CHAP-V2) will only work when the database that the RADIUS server is pointing to stores the userís NT-HASH of their password.
            • MS-Chap is designed for MS Databases
              2003-08-18 05:29:28  anonymous2 [View]

              >This is correct, but unfortunately in a PEAP(MS->CHAP-V2) exchange, the RADIUS server never >receives the clear text password from the user.

              Correct... But I think you are missing the point.
              The message above is talking about the cleartext password being available on the server side, read from a database of some kind and not sent by the client as you stated.

              >The bottom line:
              >PEAP(MS-CHAP-V2) will only work when the >database that the RADIUS server is pointing to >stores the user’s NT-HASH of their password.


              Let's think about this. To get the NT-HASH of the password on the client side you will need to NT-HASH the cleartext password typed in by the user.

              Hmmm to get the NT-HASH password on the server side you need to either have the NTHASH of the
              clear-text password OR.... have the clear-text password and NT-HASH that... so to add to your bottom line:
              PEAP(MS-CHAP-V2) will only work when the database that the RADIUS server is pointing to stores the user’s NT-HASH of their password or uses a clear-text password to create the NT-HASH.


          • MS-Chap is designed for MS Databases
            2003-07-22 06:46:25  anonymous2 [View]

            Yes the information is technically incorrect...

            But if we were to concentrate on the problem
            which is what do you do if you do not have clear-text passwords?????

            Is is not possible to create a NT HASH from, for example, a SHA1 encrypted password as used with LDAP.

            And as for Funk, they should stick their guns and push TTLS. Who the #*#* needs two eap tunneling protocols that do exactly the same...

            Sorry... I am mistaken.... three eap tunneling
            protocols... one TTLS and two PEAP (Cisco and MS).

        • Funk Software RADIUS support MS-CHAP-V2 in Solaris
          2003-07-07 17:53:52  anonymous2 [View]

          For your Information, Funk has recently released its latest RADIUS server running on the both Windows and Solaris platform.

          I have tested the solaris version and it supports Microsoft PEAP (which requires MS-CHAP-V2 for inner-authentication). It worked fine with Microsoft XP Service Pack 1 PEAP and Funk's client software 'Odyssey Client'.

          I don't think nobody can say which protocol is which. It is only the decision of the network administrators or wlan security policy admin to use PEAP or TTLS.

          But if I am, I will use TTLS with Funk. Easier but expensive.
          • Funk Software RADIUS support MS-CHAP-V2 in Solaris
            2003-10-04 09:40:16  pppeterd [View]

            TTLS and PEAP are functionally similiar. TTLS encodes data in RADIUS AVPs while PEAP is just another EAP session instead of a TLS(SSL) tunnel.

            There are some opportunities for PEAP to be more secure than TTLS. The latest drafts establish a cryptographic binding between the TLS channel and the authentication protocol itself (For example MSCHAPv2) making some man-in-the-middle attacks harder to pull off.

            Anyway lots of RADIUS servers are starting to support PEAP and or TTLS. SBR, Interlink, RadiusNT/X, Radiator..etc. PEAPs big advantage in the market can be summed up with one word.. "Microsoft". There are client options for TTLS, and some of them may be free.. But it boils down to some 90 something percent of clients running a MS operating system who already have the required software installed.
      • Clarifications
        2003-06-19 00:37:34  anonymous2 [View]

        MSCHAP? The guy is talking about MSCHAPv2....

        Haven't seen PEAP-MSCHAP yet... :P

        MSCHAPv2 needs plaint text or Microsoft NT style encrypted passwords. MSCHAPV2 uses md4 encryption.... does SQL support that? LDAP doesn't (MD5 and SHA).

        PEAP machine authentication will only work in a Microsoft NT environment.

        PEAP only supports inner EAP
        TTLS support DIAMETER which can include:
        PAP,CHAP and .... EAP.

        There are two version of PEAP. MS PEAP and Cisco PEAP. MS PEAP works best with the MS IAS and Cisco PEAP works best with the ACS.

        So everyone is doing their best as usuall...