Re: [pcp] EAP-over-PCP

Hi Alper,

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

Have you answered my question about why you think EAP re-authentication is needed for PCP, or even applies to PCP?  This is an optional part of EAP, and it's my understanding that it isn't widely used...  

Also if you do support re-authentication (after telling me what it would mean for PCP), how do you avoid exposing this paradigm to PCP, regardless of the which of the three you use?  It is no more aligned with a request-response protocol for an API to wake it up asynchronously and do re-authentication than it is for that to happen in a PCP message.

This _could_ be an argument for not using EAP, I suppose, but I don't think there has been much dissent about using an EAP-based mechanism.  I certainly don't see why we couldn't make the same simplifying assumptions in PCP that are made in GSS-EAP.  If using PANA will stand in the way of that, maybe that's a reason not to use PANA?

Margaret

> 
> 
>> 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
> 
> 
> 
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp