Subject: Re: [HOKEY] Separate local ER server from Diameter proxy [Hokey minutes]

From: Tom Taylor <[email-masked]>
Date: Tue, 12 Jan 2010 14:47:57 -0500

Responses below marked with [PTT].

Qin Wu wrote:
> Hi, Tom and all:
> In order to and better deployment scalability, I agree it is not necessary 
> to assume that the Hokey server and AAA servers or proxies are collocated
> 
> Please see my followup comments inline.
> 
> Regards!
> -Qin
> ----- Original Message ----- 
> From: "Tom Taylor" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, November 12, 2009 12:57 PM
> Subject: [HOKEY] Hokey minutes
...
> See slides for this presentation at 
> http://www.ietf.org/proceedings/09nov/slides/hokey-4.pdf. In summary, these 
> slides begin with one showing functional components and potential interfaces to 
> the local ERP server. The remaining slides show
>   - information flow requirements during the initial authentication phase
>   - possible solutions (three alternatives) to achieve this flow
> 
> [Qin]: In the three alternatives your proposed, It seems to me the third alternative may be more appropriate.
> In the first alternative where the standalone local ER server is not on the path, the authenticator did't need DSRK. why the authenticator request DSRK on behalf  of local ER server? Also in this case, it seems to require the authenticator to support ER funcationality.
> In the second alternative, although it is consist with RFC5296, more signaling overhead is required to make local ER server know DSRK.
> In contrast with the first two alternatives, the third alternative is more reasonable. because what we need in this case is to trigger local ER server to request DSRK.
> 
>   - information flow requirements during the re-authentication phase
>   - possible solutions for this phase.

[PTT] I like this one better myself, but we have to realize the architectural 
implications. First off, the authenticator has to be aware that there is at 
least one local ER server, and perhaps more than one. We'll have to describe the 
discovery process. I think two reasonable alternatives are authenticator 
configuration and SRV.

[PTT] The second point is that we now have a new interface to support, between 
the authenticator and the ER server. We will need to select the protocol and 
define the messages passing over that interface.

[PTT] Thirdly, if we want the possibility of separating the ER server from the 
EA server in the home domain, we have to decide whether the authenticator has a 
role in triggering the home ER server to fetch the information it needs during 
initial authentication, whether the EA server pushes that information to the ER 
server regardless of whether the visited domain supports ERP, or if it is 
something in the message sent from the authenticator that causes the EAP server 
to push information to the ERP server.

[PTT] Finally, we have to figure out how all of this fits with RFC 5296. One 
possibility is that we create an applicability statement limiting the use of RFC 
5296 to specific deployments.
> 
> Qin Wu sought clarification of the point about need for a "correlator", 
> mentioned on the first information flow slide. 
> 
> [Qin]: If we understand correlator as "NAI", I am afraid maybe you mix hokey authorization with DSRK request.
> In order to request DSRK, what the local ER server need to do is send local domain name to the home server.
> why we need to associate NAI with DSRK? Just for authorization on whether the local ER server is allowed to obtain DSRK?
> Would you like to clarify this?

[PTT] I shouldn't have gotten into this at the time without doing a careful 
analysis of just what information has to go where to make this all work. I was 
just trying to say that some sort of record key (thinking in database terms) is 
needed for the ER Server to retrieve the information it stored when the initial 
authentication was done. I had not done the analysis to identify exactly what 
would work, so I think the meeting discussion on this topic should be 
disregarded. I will do that analysis within the next couple of days and report back.