Re: [pcp] EAP-over-PCP

[Sam Hartman <[e-mail]>]

>>>>> "Alper" == Alper Yegin <[e-mail]> writes:

    >> Depending on what's easy for PCP implementations we have a number
    >> of options.
    >> 
    >> In RFC 3748 the conversation is conceptually server driven.
    >> However, there is typically a client (lower layer) indication to
    >> get things started.
    >> 
    >> However, the only reason that the conversation is server-driven
    >> iss retransmissions. If you take a look at section 2 of RFC 3748
    >> you note that the protocol is lockstep. The server cannot send a
    >> new request until the client has responded to the previous one.
    >> If you take a look at section 4.3, a lower layer may sent the
    >> retransmission timeout to infinite. In this mode, the server will
    >> never generate an unsolicited request.  So, it's entirely
    >> possible to view things as a client-server protocol with
    >> client-driven retransmissions if that makes things easier for PCP
    >> implementations.
    >> 

Alper>I don't understand how this works.
    Alper> EAP authenticator performs rexmits.  So, if it does not get a
    Alper> response, it'll keep rexmitting. So, how can you achieve
    Alper> "server will never generate an unsolicited request"?

There are three aspects to this: why does it work in practice, why does
it comply with the spec, and why do I think  it's been reviewed
adequately to suggest it?

For the first, EAP libraries tend to have a way to ignore  retransmits
or set the retransmission timeout to infinite.
Consider what happens in an AAA server. There, your EAP server cannot
(and is not supposed to) handle retransmits.
RADIUS at least is a lock-step protocol. Ignoring things like COA, a
RADIUS server cannot send an unsolicited response to a client.
So any EAP server library basically has to have a way to disable
retransmits.
I guess it's possible that you could have a passthrough authenticator
library that doesn't pull this off.
IN practice we've not run into this problem; see below for why.

Also, as I understand it (without close reading) the IKEv2 EAP support
works this way as well.

So, why does it comply with the spec?
Take a look at RFC 3748 section 4.3. That section points out a lower
layer can set the retransmit timeout to infinite if it is reliable
itself.

Why do I think the whole idea of assuming you'll never get an
unsolicited server request has been adequately reviewed? It's part of
draft-ietf-abfab-gss-eap, which has already been approved and is waiting
publication. I've personally walked through what we were doing with
Bernard; I know Joe is familiar with the work enough that he understands
our state machine constraints. Klaas is one of the chairs; he also has a
lot of EAP experience. Josh Howlett, my co-author has many more years of
EAP experience than I do.  So, I believe that this idea has received
adequate review that if I were somehow misreading the base EAP spec we
would have noticed it.


    Alper> And, furthermore, there'd be EAP re-authentication which can
    Alper> be initiated by the client or server. This is another reason
    Alper> for having to support server-side requests.


I'm not entirely sure what you're talking about when you say EAP
re-authentication.
Do you mean the EAP re-authentication protocol (the one done in HOKEY?)
The base EAP spec mentions re-authentication once or twice  but does not
define it.
My best reading of that text is that they simply mean there can be later
EAP conversations if you want to access a new resource or the like, or
the network wants to re-key, or prove fresh access to tokens or
whatever.


When you look at the peer state machine in RFC 4137, you note that the
success state is a final state.
It's going to require lower layer interactions to get out of that state.
If you look at the commen open-source supplicants (all I have access to)
you see that tends to be how people implement things.
You expect a disassociation or something else to trigger new
authentication.
And when that happens, yes, depending on who's doing the trigger and
what's going on, the first *EAP* message may be from the server.

In our proposal, PCP is the same way.  A server can throw away a session
and give a client an error that they must authenticate again if it wants
an EAP exchange.  This is intended to deal with wanting to expire
sessions or servers that lose state.  However it also deals with a
server wanting to confirm freshness, or getting a re-authentication
demand via some complex AAA infrastructure that seems unlikely to be
used with PCP in practice.