eap Mailing List: Review of draft-clancy-eap-pax-01.txt

[Bernard Aboba (aboba]

Note:  This is not an RFC 3748 compliance review, just my personal
comments on the spec.

Abstract:

"avoids intellectual property rights associated with competing EAP
methods."

This could be misconstrued as providing legal advice.  I'd rework or
delete it.

"PAX_IDP is a variant that additionally provides identity protection, and
requires a server-side certificate."

Later on (in Section 4.1) it says:

"   Use of self-signed certificates with client-side SSH-style caching is
   only suggested if identity protection is required and a PKI is
   infeasible.  When identity protection is not used, self-signed
   certificates provide no additional security over no signatures at
   all."

I'd move that material up to the front so that the server-side certificate
"requirement" is clearer.

Section 1

"  While the preferred mode of operation is for the server to have a
   certificate it can supply to the client when a weak key is being
   used, the protocol supports a purely symmetric-key mode of operation
   when identity protection is not required. "

Same comment as in the abstract, relating to the use of self-signed certs
as described in Section 4.1.

"   EAP-PAX includes built-in key management features, resistance to
   dictionary attacks, and avoids intellectual property issues
   associated with protocols such as EKE [BM92], SPEKE [Jab96], and SRP
   [RFC2945]. "

Again, this statement might be construed as providing legal advice.  I'd
rework or delete it.

Section 2.1

"   The full protocol, when server-side certificates are used is as
   follows:

   o  PAX_STD-1 : client <- server : A, SID, PK, CertPK
   o  PAX_STD-2 : client -> server : Enc_PK( B, MAC_CK( A, B, CID, SID
      ))
   o  PAX_STD-3 : client <- server : MAC_CK( B, CID, SID )
   o  PAX-ACK   : client -> server"

Some comments:

a. This protocol would also work without a server-side certificate,
although that would introduce an initial active man-in-the-middle
vulnerability.

b. It seems like this protocol doesn't send the client id at all (just a
MAC computed over it).  Or am I missing something?

"   When not performing an initial key update, where server-side
   certificates can be omitted, the protocol reduces to:

   o  PAX_STD-1 : client <- server : A, SID
   o  PAX_STD-2 : client -> server : B, MAC_CK( A, B, CID, SID )
   o  PAX_STD-3 : client <- server : MAC_CK( B, CID, SID )
   o  PAX-ACK   : client -> server"

Here it appears that the client identity is not sent at all, only
the server identity, correct?  I'm a bit confused by this, since A & B
are new fresh values, right? It would therefore seem like there is no
session-id to identify the previously provisioned key.  Also, are A & B
being used to refresh the master key as in TLS?  It seems like they are,
given the statement in 4.3.10:

"  Session keys are independently generated using fresh nonces for each
   session, and therefore the sessions are independent."

General question:

How are the keys created by the protocol identified?  For example, what
constitutes an EAP session-id within this protocol?

Section 2.2

"  o  PAX_IDP-1 : client <- server : M, SID, PK, CertPK
   o  PAX_IDP-2 : client -> server : Enc_PK( M, N, CID )
   o  PAX_IDP-3 : client <- server : A, MAC_N( A, CID, SID )
   o  PAX_IDP-4 : client -> server : B, MAC_CK( A, B, CID, SID )"

Maybe I'm missing something, but I don't see how PAX_IDP provides more
identity protection than PAX_STD in the key update mode.  Both protocols
send the serverid in the clear and can encrypt the clientid.  Or is the
difference when the initial key update is not being performed?  Since
PAX_STD doesn't send the clientid there either, I'm not sure what the
difference is.

Section 2.4

"  PAX_STD-1/PAX_IDP-1 -> Client : If a public key and certificate are
   included, the client SHOULD either compare the public key to a
   locally cached copy or use the certificate authority's public key to
   validate the server's public key and certificate.  If this validation
   fails, and the client's security policy prohibits the use of a
   non-verifiable certificate, then the client MUST send an EAP-Failure
   message."

So presumably the certificate could be self-signed, or even omitted
altogether (just the PK being sent).

"  PAX_STD-2 -> Server : After possibly decrypting the packet, the
   server MUST validate the included MAC.  This MAC serves to
   authenticate the client to the server.  If this validation fails, the
   server MUST send an EAP-Failure message."

Not sure how this works since neither a clientid nor a sessionid is
included in the PAX_STD-2 message.  So how does the server validate the
included MAC?

"
   PAX_IDP-2 -> Server : The server MUST verify that the decrypted value
   of M matches the value transmitted in PAX_IDP-1.  If this validation
   fails, the server MUST send an EAP-Failure message."

I think you want to include a definition of M in the terminology section.

Section 3.1.4

Are only DH Group IDs defined? For example, is it possible for this
protocol to support elliptic curve?

Section 4.1

"  Since many vendors are leery of establishing a public key
   infrastructure (PKI), or the client-side computation power needed to
   implement them, some discussion is required with respect to the PKI
   requirements of this protocol.  First of all, realize that only the
   server needs a public key.  The client is authenticated based on the
   shared secret, not a key pair.  This should make deployment
   significantly easier."

Since EAP methods requiring a server-side certificates are already widely
deployed, it seems like the primary unfilled need is for a protocol that
does not require certificates on either the client or the server.
The client-side computation power issue will arise I think because of the
requirement for a 3072-bit MODP group.  This might be ok within an
initial provisioning phase, but there are embedded devices (such as
phones) that may want identity protection, and requiring this on every
authentication would be a problem.

"The only other possibility is to use an aliasing scheme where users are
given new usernames after every successful authentication--generally
considered a fragile approach, prone to synchronization problems."

I think there is a distinction between a new username and a sessionid.
Sessionids are widely used to identify keys (e.g. in TLS) and to my
knowledge have not been shown to be prone to synchronization problems.

"   When using cached self-signed certificates in PAX_IDP, realize that
   clients have no way to authenticate the authenticator before sending
   them their identity.  An attacker could impersonate an authenticator
   and gain knowledge of the client's identity.  In a roaming wireless
   environment, this attack becomes much easier since the client could
   possibly interact with multiple authentication servers.  Provided a
   client positively knows they will only interact with one backend
   authentication server, even when roaming a self-signed, cached
   certificate approach may be sufficient, depending on one's threat
   model."

As noted earlier, I'm not sure where the clientid is sent in PAX_IDP.
Might this vulnerability be reduced via use of a session-id?

"   In short, in identity protection mode, certificates are required, and
   use of cached self-signed certificates can lead to man-in-the-middle
   attacks the first time a client interacts with a particular
   authenticator.  "

It seems to me that the first-time vulnerability is not as serious as the
vulnerability occurring during a subsequent key update.  Presumably the
initial provisioning can be handled by IT staff, but the user has to deal
with the subsequent key update, and is presumably much less
knowledgeable/trustworthy.

Section 4.3.9

"   While a specific fast reconnection option is not included, execution
   of EAP-PAX requires such minimal effort that the time required to
   perform a full reauthentication is not prohibitive."

Not sure this is true for the case where identity protection is required
and a 3072-bit MODP group is used on every authentication.