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

From: Bernard Aboba <[email-masked]>
Date: Thu, 06 Jan 2005 15:27:21 -0800

"Self-signed server certs could be preloaded onto clients, or clients could use SSH-style caching."  

[BA] I do see a distinction between self-signed certs and SSH-style caching of PKs for several reasons:

1. Peer-to-peer vs. client/server operation.  Protocols that are symmetric with respect to credential requirements can more easily be used in peer-to-peer scenarios such as 802.11 adhoc or 802.1af bridge-bridge authentication.  This is a significant hole today, since most EAP methods are client/server. 

2. Footprint.  Certificate-handling code is a significant contributor to footprint, which can be important for embedded applications such as phones.  There may be devices that can handle public key computation yet which may require long battery life and therefore would prefer to dispense with certificate support.

3. Performance.  Even self-signed certs may sometimes be large enough to cause fragmentation.  

Given these issues, I think that a certificate-less option would provide more usage scenarios for EAP PAX, with all the caveats you've described. 

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

[BA] Yes, especially since the EAP-Response/Identity may be "decorated" and edited by AAA proxies, causing the MAC to fail to verify. 

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

[BA] I think it's helpful so as to understand conceptually how the key cache is maintained.  There is also some discussion in the EAP Key Management Framework about the EAP Session-Id. 

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

[BA] When a "privacy" NAI is sent in the EAP-Response/Identity, the EAP server needs to decide what method to use without knowing the peer identity.  The RFC 2486bis defined privacy format is "@realm", although "anonymous@realm" is sometimes used.  When privacy is requested, the EAP server will typically be configured to respond with an EAP method supporting privacy.  

"There are lots of representation issues with ECC, so it might be easiest to refer to another RFC for its definition."

That's fine, but it might be useful to clarify the intentions for allocation of the parameter in the IANA considerations section (you'll need a registry to be set up). 

"Identity protection does not require the 3072-bit DH, only the 2048-bit RSA."

OK, I missed that.   

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

[BA] Yes, I would make that argument.  Typically we distinguish "identity protection" from traffic analysis.  For example, in IKE we can't hide the source and destination IP addresses, but in Main Mode we can encrypt the identity payloads. 

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

[BA] It would be nice to be able to use PAX_IDP with raw PKs in this kind of scenario.  The downside is the potential for rogue server attacks as we have seen with SSH.  This could be an issue when roaming to untrusted networks (where a rogue AAA server could exist on the wired network). 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap