Subject: Re: [eap] Review of draft-clancy-eap-pax-01.txt

From: Charles Clancy <[email-masked]>
Date: Thu, 6 Jan 2005 17:39:15 -0500 (EST)

Thanks for the review Bernard.  See comments are inline.

> Abstract: 
> 
> "avoids intellectual property rights associated with
> competing EAP methods."
> 
> This could be misconstrued as providing legal advice.  I'd rework or
> delete it.

Agreed.

> "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.

I'd like a little more WG discussion on the certificate issue as a
whole, and what the draft should even include.  Server-side certs are
necessary to do provisioning and identity protection.  Use of
non-CA-signed certificates becomes sticky, because then it's up to the
client security policy to decide if they are acceptable.  Self-signed
server certs could be preloaded onto clients, or clients could use
SSH-style caching.  All these different scenarios increase the
security risk over using real CA-signed certs.  How much of this
should be normative text, and how much should be implementation
guidelines?  We can't really restrict what types of certs are used in
PAX, since cert validation is typically independent of the protocol,
and so many different configurations are possible.  Should I attempt
to enumerate every possible configuration, and give security guidance?

> 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.

This issue is a little different.  Since certs with unauthenticatable
origin provide no security benefit during provisioning, PAX supports
leaving them out completely.  This allows for a very small window of
attack during the initial authentication and requires an active, MitM
adversary.

> "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.

Agreed.

> 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.

Yes, as was previously described, and why omitting the certificates is
supported.

> 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?

Ah, this was using the assumption that CID = EAP-Identity/Response.
However, I changed CID to be the client NAI in v01.  The CID should be
explicitly sent as well.

> "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."

Same comment as above.  Before CID was the EAP Identity, and now that
it's the NAI it should indeed be included.

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

I had thought of including something like the TLS PMKID, but wasn't sure
if it was necessary.

> 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.

The difference is that in PAX_IDP, the EAP-Identity/Response will
contain bogus data.  Perhaps some sort of predefined string such as
"PAX_IDP@REALM" should be included in the draft.  In PAX_IDP, the CID
needs to be securely sent to the server, whereas in PAX_STD, it can be
sent in the clear.  Does the EAP client NAI include the
EAP-Identity/Response?  I'll have to double check.  If not then the
client username should be included in PAX_IDP-2.

The goal of PAX_IDP is that nothing user-specific occurs on the server
before PAX_IDP-3.  This allows the user to first obtain the encrypted
username, and then decide which key should be used.

> 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).

Yes.  This leads back to all the different PKI possibilities, and how
many of those we wish to address in the PAX document.

> "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?

Right, CID needs to be included since it's not the same as the Identity
anymore.

> "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.

M and N are included in section 1.2, under the "Variables" heading.

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

It's meant to be extensible.  Right now only one group is defined.
ECC groups are welcome, as long as they provide a comparable level of
security.  There are lots of representation issues with ECC, so it
might be easiest to refer to another RFC for its definition.

> 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.

Identity protection does not require the 3072-bit DH, only the
2048-bit RSA.  You technically only need DH during provisioning.
Right now I'm requiring it if a new AK is being derived, to promote
forward secrecy.  This would probably only happen once every few weeks
though, depending on your configuration.

> "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.

Unless the sessionids are changed after every use, then this isn't
real identity protection.  Of course, one could argue that the same
client MAC address is used every time, so that could just as easily be
used for correlation by some adversary.

> "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?

See section 2.2.  It's sent in PAX_IDP-2.  Presumably you'd always be
talking to the same AAA server when authenticating, so SSH-style
caching in PAX_IDP would be fine.  The very first time you
authenticate you might be vunerable to a MitM though.  Session IDs
wouldn't do much good because no session has ever been established
during the vunerability window.

> "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.

Indeed.  If provisioning occurs in a controlled environment with a
reduced threat model, then life is good.  No certs are needed for
PAX_STD, and self-signed certs (as long as the client has seen the
cert before) are fine for PAX_IDP.

> 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.

As I mentioned before, the 3072-bit MODP group is only needed when
doing a key update.  99% of the time, authentication looks like:

client <- server : X, SID
client -> server : Y, MAC_CK( ... )
client <- server : MAC_CK( ... )

where CK = MAC_AK( X || Y || ... )

All you need is a few hashes.  No DH.

Overall, I think the protocol is pretty simple.  The biggest area
where it gets complicated is my attempts to be flexible with how the
public-key features are used, when trying to cater to many different
threat models.

I've been planning to submit a v02, but haven't had the time to do so
yet.  It will include some minor editor changes, specification of the
RSA-OAEP parameters, and the following based on Bernard's comments:

  - removal of IPR comments
  - inclusion of the CID in PAX_STD-2
  - cleaned up introduction that better discusses the PAX operating
    modes with respect to certificates

I'm interested in people's thoughts regarding the how much should be
included in the draft regarding PKI requirements, as discussed above.

Thanks!

[ t. charles clancy ]--[ [email-masked] ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Fri, 07 Jan 2005 13:34:20 +0200

Charles,

I'm working on the official expert review of your spec.
This review is not ready yet, but in the meantime I do
have some early comments and questions:

Overall, I like PAX a lot. It seems to provide what I
would like to have from an EAP method, in a reasonably
simple & clear manner, and we can rely on its security.
Personally, I would like to see PAX on the standards track,
in fact.

Substantial:

> This Internet Draft defines a provably secure Extensible
> Authentication Protocol method called EAP-PAX.  This method is
> designed for bootstrapping a shared key-based authentication protocol
> with a weak preshared password or PIN.  It includes key management
> features, is secure against dictionary attacks, includes optional
> support for identity protection, and avoids intellectual property
> rights associated with competing EAP methods.

As Bernard noted, you should probably delete the IPR related
statement.

> SID
>    EAP server NAI [RFC2486]

I am not sure whether this is appropriate. We generally do not use
NAIs for server side identification; there may be issues here that
no one has thought of. Or maybe not. The use of NAIs for SIDs works
nicely in peer-to-peer situation. In any case some discussion
about this usage would be useful.

Can one server support more than one domain? If so, how would it
guess which identity to send to the client?

Also, you seem to have several types of identities for the
server side, including both the SID, the various identifiers
from the server's cert, and the public key itself. Some
clarification in the use of those identifiers would be
desirable.

> 2.2  PAX_IDP Protocol
> 
> PAX_IDP is an alternate protocol designed to provide identity
> protection.  The main disadvantage of PAX_IDP is that it requires a
> server-side certificate, and public key operations for every

There seems to be a number of modes in the protocol. I wonder
if you could combine the modes that do require a cert into
just one, which would provide both key update and identity
protection? Or is the interest in avoiding PK computations
on some authentications the reason for the additional mode?

> 2.4  Verification Requirements
> 
> In order for EAP-PAX to be secure, certificates and MACs must be
> properly verified each step of the way.

This is a necessary, although perhaps a bit imprecise
requirement.  What specific verifications regarding certificates need
to be performed? For instance, are there some requirements regarding
the SID and certificate name comparisons? Which identifier is the one
that matters, by the way? (E.g., is shown to the user.) Is there a
requirement to compare the EAP Identity Response contents in some
manner to CID or the certificate? Or perhaps only the domain part.
Etc.

> 3.1.6  Sequence Number
> 
> Sequence numbers are used to prevent replay attacks, in particular
> with respect to ACKs.  The server initializes the sequence number to
> 0 for each transaction, and increments it for each packet.  For every
> EAP-Request/PAX packet fragment transmitted the associated
> EAP-Response/PAX packet MUST contain a matching sequence number.
> Packets with invalid sequence numbers MUST be silently discarded.

Perhaps I do not understand the role of the sequence number well
enough. It seems like EAP identifier already covers the matching-not
matching response case. What additional value does the sequence
number field give here? I would understand this better if the server
kept a global or long-term sequence number counter, but you say that
its initialized to 0 "for each transaction", presumably meaning each
EAP protocol run.

>  executed, the server-side certificate is required.  Without using
>  some form of authenticated public-key cryptography, identity
>  protection with forward secrecy is theoretically impossible.

Just out of curiosity, is there a reference that states this?

> 4.3.12  Channel Binding
> 
> EAP-PAX does not explicitly include any channel binding.

As far as I can see, the method's non-AVP format does not lend
itself easily for extensions, such as channel bindings. This would
make it hard to implement draft-arkko-eap-service-identity-auth on top
of PAX. Or how would you do it, by adding a new flag? But how would
the peers be able to skip the unrecognized AVP? Personally, I'd like
to see binding features in PAX, preferably in a general form that does
not make channel information in PAX completely separate from the
channel information in other methods...

> Two of the biggest challenges in an enterprise WiFi network is key
> provisioning and support for multiple devices.  Consequently, it is
> recommended that the client's NAI have the format username/KID@realm,
> where KID is a key ID that can be used to distinguish between
> different devices.

Hmm... I wonder if the users need to be burdened with this. Presumably
the peers already have a lot of information about the specific devices
that are in use (e.g. MAC address), so why would additional information
be needed in the NAI?

> Provisioning could easily be accomplished by issuing a customer a
> 4-digit PIN they could type into their phone's keypad.

Does this mean that if I know you have been assigned a NAI
[email-masked] but you have not yet used it, I need to run

	0.5 * 10,000 = 5,000

authentication runs, on the average, to the server before hitting
a value that the server recognizes as valid? And from there on
*I*, not you, own the generated key which is used for subsequent
authentication?

Editorial:

> While the preferred mode of operation is for the server to have a
> when identity protection is not required.  However, in this mode the

The above statement was hard to parse.

> EAP-PAX includes built-in key management features, resistance to

Maybe s/avoids/we hope it avoids/

>    CID
>       EAP client NAI [RFC2486]

Reference to RFC2486bis (draft-ietf-radext-rfc2486bis-03.txt) might be appropriate
here.

>  The EAP framework [RFC3748] defines four basic steps that occur
>  during the execution of an EAP conversation between client and
>  server.  The first phase, discovery, is handled by the underlying MAC
>  protocol.  The authentication phase is defined here.  The key
>  distribution and secure association are handled differently depending

s/association/association phases/

> o  PAX_STD-2 : client -> server : Enc_PK( B, MAC_CK( A, B, CID, SID

s/SID\n\t))/\n\tSID))/

---

From: Jari Arkko <[email-masked]>
Date: Fri, 07 Jan 2005 13:51:20 +0200

> M and N are included in section 1.2, under the "Variables" heading.

I also missed them on the first reading -- because they are on the
same line as the other variables. Maybe put them on their own line,
for ease of finding them from the section?

>> considered a fragile approach, prone to synchronization problems."

(I suppose the fragility of the aliasing scheme depends a bit on how
the protocol is defined.)

> used for correlation by some adversary.

This is indeed true. And as far as I understand, IEEE has been
pretty insistent on the use of administratively assigned, fixed
MAC addresses, so I'm not sure when solutions will arrive to remove
the issue on the lower layer. Current typical requirements for
EAP methods do not seem to match the status of the rest of the
stack. Nevertheless, I think PAX and other new methods should
have high quality identity protection. I don't think a long
term session ID is going to cut it. We need something that
changes on every or at least every few authentications. Preferably
I would change my identity every time I change my link.

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 8 Jan 2005 16:07:07 -0800 (PST)

> I would change my identity every time I change my link.

In reading through various drafts that deal with "privacy" (including CUI)
it would appear that they're not using the same definition.  For example,
one of the purposes of CUI is to allow correlation between sessions
so that the same CUI may be used for multiple sessions.

Also, EAP authentication does not necessarily occur on each link
change (e.g. 802.11 PMK caching) and in 802.11 there are several means for
session correlation, including the source MAC address and the PMKID.

As a result, on some media changing the id on each link may either not be
possible, or may not prevent correlation.  In other situations the
operator may only partially support privacy or may not support it at all.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Sun, 09 Jan 2005 09:45:20 +0200

> operator may only partially support privacy or may not support it at all.

Yes. The definition of privacy is complicated through having
multiple pieces of information that you want to protect, as
well as having different entities that you want to protect
it from. You may want to hide

- Your true identity (e.g. [email-masked])
- Trackable identity (e.g. a MAC address, a key ID, or a home address)
- Characteristics of your device
- The contents of your communications

This is further complicated by the fact that most of this
applies to not just one, but all protocol layers. Another
complication is that identifiers may have different
lifetimes (e.g. NAI vs. key ID).

The question of what entities you want to protect the information
from is interesting from the perspective of EAP and AAA.
Traditionally, we want to protect it at least from complete
outsiders. But it can also be useful to avoid revealing things
to all network entities, even if they are assisting you in
some manner (such as providing access). EAP was not originally
designed to protect information even from complete outsiders,
as EAP identity response is in the clear. Methods have, however,
attempted to correct this situation is various ways. This has
been successful, and in the process we have actually also managed
to protect information from some of the insiders, the access networks.
I guess part of the reason why we are discussing CUI is that these
improvements have been, in a way, in a partial conflict with
some business requirements. But we need to make sure that
we don't end up revealing the information to complete outsiders
in the process.

--Jari