Re: [pcp] EAP-over-PCP

[Alper Yegin <[e-mail]>]

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

You mean the "EAP layer"? 

  When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as
   within [PIC]), the authenticator retransmission timer SHOULD be set
   to an infinite value, so that retransmissions do not occur at the EAP
   layer. 

Only when run over a reliable EAP lower layer, the EAP layer sets the timeout to infinity.
So, whether the rexmit is handled by the EAP layer, or the EAP lower layer, the PCP server will be sending retransmissions in your case.


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

Ah, "ignoring CoA". CoA is the RADIUS' tool to generate an unsolicited message, more specifically for starting EAP re-authentication.
So, let's not ignore that.


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

Rexmit is the responsibility of the "EAP passthru authenticator".


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

True. But see my explanations above.


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

Sam, you are claiming "it's entirely possible to view things as a client-server protocol with client-driven retransmissions if that makes things easier for PCP implementations."
I don't see how it works from your technical explanations here. 
You are referring to a past work, which I was not involved. Unless I go back and read that spec, and email archives, I cannot know why/how/what happened, and if it's applicable to here.

So, why don't you just explain us how it'd work, better yet show us on your document.

Bottom line is, 
EAP is server driven.
PCP is client driven. 
How do you stack them up against each other?


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

No, not that. That's just an optimized re-authentication.
Re-authentication is executing EAP again.

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

You got it.

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

You want service continuity. So, you don't use disassociation. EAP re-authentication is performed while the existing EAP session is still good and other layers are still using the unexpired security association.


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

There you go.

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

First of all, this is not in your document. 
Secondly, this is a bad design. As soon as the network side decides to re-auth, it's should be able to do so. It shouldn't have to wait for the client to make the next contact.

Alper