Re: [pcp] gss-eap & client-side rexmit only

[Alper Yegin <[e-mail]>]

Sam,


> 
>>>>> "Alper" == Alper Yegin <[e-mail]> writes:
> 
>    Alper> Sam, You claimed you can design an EAP lower layer that's
>    Alper> always client driven, and gave GSS-EAP as an example of how
>    Alper> you did it.
> 
>    Alper> So, I had already looked at it and still don't see it how.
>    Alper> See below for the last email I sent on this matter which went
>    Alper> unanswered.
> 
> Hi Alper.
> I think I've done a number of things to try and walk you through this:
> 
> * We've had multiple discussions on the list where we discussed whether
>  this was possible in the EAP spec

EAP spec talks about delegating the reliable delivery from EAP layer to the EAP-lower layer.
it does not talk about turning the req/resp direction 180 degree from network-driven to client-driven.
So, I don't really find comfort in reading RFC 3748 when it comes to supporting your approach.

> * I pointed you at the gss-eap specification
> * I gave textual explanations of how it works
> * I went over it on the call again yesterday
> 


Honestly, we need to dig deeper. See the kind of example Yoshi gave in his last email and let's see how such a thing works.


> * During the PANA implementation discussion  I pointed you at an
>  open-source implementation of GSS-EAP and particularly pointed you at
>  the part of the code that interacts with the EAP library.
> 
> Other people do seem to be following this issue at this point, so I'm afraid we're talking past each other.
> I'm sorry about that, but perhaps it would make more sense for you to try and
> 	work with someone else on this issue.
> If there are PCP implementors on this who need to discuss this in more detail
> 	I'd be happy to try and help as I can.


I have to admit I had missed your earlier email on CoA discussion, sorry.
Here's what you had said, and my comments:

   Alper> Ah, "ignoring CoA". CoA is the RADIUS' tool to generate an
   Alper> unsolicited message, more specifically for starting EAP

Sam> I'd like to draw the WG's attention to RFC 5176, which defines COA.
Sam> Section 4 explicitly mentions that COA cannot be used for starting
Sam> re-authentication.  

You are reading a special section on RADIUS-Diameter interworking.

If you look at the table of attributes on page 21, you see the "CoA request" can carry 0+ EAP message.
So, the NAS (PCP client) can receive an asynchronous EAP request from the AAA.


Sam> Section 1.1 is an applicability statement explaining
Sam> why COA is not standards-track because of security and semantic
Sam> concerns.

So, you want to pretend RADIUS CoA does not exist? It's used in the industry, cannot ignore.


Sam> As best I can tell only diameter has AAA support for re-authentication.
Sam> So, I'd like to draw our attention to RFC 4005, section 3.3 which
Sam> defines rules for diameter re-authentication.  That section explicitly
Sam> calls out re-authentication must be supported *if the underlying service
Sam> supports it*.  That is, re-authentication is OPTIONAL for a given
Sam> service like PCP, but if a given PCP server supports re-authentication
Sam> and diameter, then it needs to support re-authentication via diameter.
Sam> Section 3 of RFC 4072 (diameter over eap) confirms the guidelines of RFC
Sam> 4005 apply.

I had said:

> - What happens if server-side needs to re-key, extend lifetime, change authorization, re-challenge the client? 
> Say, the acceptor receives a RADIUS CoA with EAP-Request, what's going to do with it?



So, if you want to prohibit use of server-initiated re-auth, prohibit use of CoA for now and for future, you need to tell us how none of the above is ever needed.

I think you have a very particular way of using EAP and AAA in mind, nothing like the standard ways of using these protocols. We need to understand your model, and why your model shall be the only model that we'll ever see with PCP.

Alper










> Date: Thu, 18 Oct 2012 09:24:51 -0400
> In-Reply-To: <[e-mail]> (Alper Yegin's
> 	message of "Thu, 18 Oct 2012 09:04:43 +0300")
> Message-ID: <[e-mail]>
> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)