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

From: Alper Yegin <[email-masked]>
Date: Thu, 18 Oct 2012 09:04:43 +0300

Sam,

You claimed you can design an EAP lower layer that's always client driven, and gave GSS-EAP as an example of how you did it.

So, I had already looked at it and still don't see it how.
See below for the last email I sent on this matter which went unanswered. 

Please take a stab at it and let's progress this discussion.

On Sep 20, 2012, at 4:17 PM, Alper Yegin wrote:

> So, I looked at this spec.
> 
> This, too, is server-driven. Like EAP is, unlike PCP is. 
> Retransmission do happen, not at the EAP layer but at the EAP-lower layer.
> 
> Yep, there's no re-auth. It's absence is confirmed! :-)
> 
> - 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?
> 
> Sorry folks, gss-eap as an EAP lower layer spec is incomplete. Whether you recognize and accept this today, or later when you start building complete architectures/systems with it. No worries, you can always add it.
> 
> Alper
> 
> 
> 
> 
> 
>

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 18 Oct 2012 07:46:21 -0400

Hi Alper,

>> Yep, there's no re-auth. It's absence is confirmed! :-)

Does this mean that you think it is okay not to allow server-side reauthentication?  You wrote this before the call, but seemed to say otherwise on the call.

>> Say, the acceptor receives a RADIUS CoA with EAP-Request, what's going to do with it?

If the PCP Server determines (for any reason) that the authentication information is invalid, it will invalidate it.  There is no reason to inform the client (or an enforcement point, or anyone else) that the information has been invalidated at that time, because _unlike the PANA case_ there is no need to block any ongoing session and/or any ongoing traffic from the PCP client to other nodes.  The client can find out that the authentication information has been invalidated when/if it sends a PCP request using the now-invalid authentication information.  This will cause the PCP Server to return an authentication error, and the client will attempt to re-authenticate.

>> Sorry folks, gss-eap as an EAP lower layer spec is incomplete. Whether you recognize and accept this today, or later when you start building complete architectures/systems with it. No worries, you…

This is an issue you should raise with the abfab WG, i guess.  I don't think they will agree with you.

Margaret

---

From: Sam Hartman <[email-masked]>
Date: Thu, 18 Oct 2012 09:25:13 -0400

>>>> "Alper" == Alper Yegin <[email-masked]> 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
* 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

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 19 Oct 2012 00:31:56 +0900

Margaret,

(2012/10/18 20:46), Margaret Wasserman wrote:
> If the PCP Server determines (for any reason) that the authentication information is invalid, it will invalidate it.  There is no reason to inform the client (or an enforcement point, or anyone else) that the information has been invalidated at that time, because _unlike the PANA case_ there is no need to block any ongoing session and/or any ongoing traffic from the PCP client to other nodes.

This is not true for tightly-coupled authentication/authorization 
model.  Tightly-coupled
authentication/authorization model (which is typical in AAA architecture)
needs to be supported, and in tightly-coupled 
authentication/authorization model,
support for server-initiated re-authentication makes a lot of sense.  
This does not
mean clients cannot sleep.  Clients can sleep but they may just miss to 
receive
server-initiated re-authentication requests, and if that happens they 
will need to start
full authentication, which is fine.   I don't disagree with additional 
support of loosely coupled model,
but I disagree if you say tightly-coupled authentication/authorization 
model is not needed.

Yoshihiro Ohba

> The client can find out that the authentication information has been invalidated when/if it sends a PCP request using the now-invalid authentication information.  This will cause the PCP Server to return an authentication error, and the client will attempt to re-authenticate.
>
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp
>

---

From: Alper Yegin <[email-masked]>
Date: Mon, 22 Oct 2012 12:53:21 +0300

Sam,

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

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

> 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