eap Mailing List: Re: Another review of draft-clancy-eap-pax-01.txt

[Charles Clancy (clancy]

On Fri, 7 Jan 2005, Jari Arkko wrote:

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

Sorry for the response delay.  I'm trying to get version 02 put together 
before IETF 62, and am finally looking over the comments.

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

The provable security requires these hashes include the server's identity, 
and it should somehow be verfiably the same as the CN specified in the 
certificate.  Also, there should be something in the certificate that 
indicates AAA authority over a domain.  How does this work in EAP-TLS? 
In an organization that signs user and host keys, what prevents me from 
using my valid user key with matching domain to spoof a AAA server?

I think that for a AAA server managing multiple domains, this would be 
disambiguated by the EAP-Identity/Response message.  It would have to 
include an @DOMAIN in order for the server to validate the client 
credentials anyway.

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

Basically you have the following modes:

STD w/ cert: provisioning
STD w/o cert: insecure provisioning, regular authentication
IDP w/ cert: identity protection (regular and provisioning)

I could eleminate "STD with certificate".  Plus you'd get the bonus of 
identity protection (though you'd probably already have leaked it in the 
EAP-Response/Identity).

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

The CID should match the EAP-Response/Identity modulo the AP-added 
decorations.  The SID should match the certificate CN.  These are things I 
will address in v02.

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

I think you are right.  Even a running counter wouldn't do much to stop a 
replay attack.  The goal was to prevent an attacker from sending forged 
PAX-ACK packets.  These are sent as the second client response in PAX_STD 
and in response to fragments in PAX_STD-1 and PAX_IDP-1.  Of course, the 
CK hasn't yet been generated by PAX_*-1, so there is no integrity 
protection.  The numbers could be easily changed by an attacker.

I'll remove this field.

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

Well you end up with the basic paradox of needing to know the username to 
figure out which key to use to decrypt the username.  There are some ways 
to *kind* of get around the problem by providing partial information to 
the server about the client, but that same partial information is also 
provided to an attacker.

It's probably best to just remove that claim.

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

Hmm... the goal was to keep PAX as simple as possible and still meet the 
"EAP Method Requirements for Wireless LANs".  What do others on the list 
think about this?

> > 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 [at] 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?

I suppose username+MAC would uniquely identify users in every situation 
you can think of off the top of your head.  I'm sure there would be cases 
where that might be insufficient though.  These are just some 
implementaiton suggestions.  How appropriate would they even be for a 
standards-track draft?

> > 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
> charles [at] example.com 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?

Yes.  Should I include text on preventing online dictionary attacks?  It 
seems like a fairly obvious security practice.

[ t. charles clancy ]--[ tcc [at] umd.edu ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]