Subject: Re: [Emu] If we use the Radius property extension

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 3 Aug 2009 15:13:14 -0700

> -----Original Message-----
> From: Richard [mailto:[email-masked]] 
> Sent: Monday, July 27, 2009 2:57 PM
> To: Dan Harkins
> Cc: Joseph Salowey (jsalowey); [email-masked]; 
> [email-masked]
> Subject: Re: [Emu] If we use the Radius property extension
> 
> Hi, Dan:
>  
> Thanks for your comments. Please check my comments inline 
> which is identified by [Richard].
> 
> 
> 2009/7/28 Dan Harkins <[email-masked]>
> 
> 
> 
> 	 Hi Richard,
> 	
> 	[Dan] On slide 11 you say you want to reuse the AAA 
> architecture.
> 	But EAP is not a AAA protocol. RADIUS is but you don't want to
> 	use RADIUS. So I don't understand what reuse you're hoping to
> 	take advantage of.
> 
>    
> //////////////////////////////////////////////////////////////
> ////////////
>    [Richard] Yes, I want to reuse the AAA architecture. This 
> is a main objective
>    and the reason for it is described on the slide 9.  For 
> the reusing,
>    there are two methods. One is the Radius property 
> extension and it is a direct
>    way to reuse the AAA; Another way is to make the WAI over 
> EAP. As the Radius 
>    has a EAP property, so WAI over EAP establish a bridge to 
> reuse the AAA. 
> 
[Joe] EAP is a protocol to authenticate an EAP Peer that communicates
between the EAP Peer and an EAP Server.  EAP is not an alternative to a
AAA protocol.   

> 	
> 	[Dan]Since EAP doesn't have a transport how do you 
> propose to send
> 	EAP packets from the AP to the server? Over UDP port 3810? The
> 	same port you send WAI packets to now? If that's the case then
> 	all EAP is doing is providing a needless encapsulation of your
> 	WAI packet. You gain nothing by encapsulating your WAI packet
> 	with an EAP header.
> 
>    
> //////////////////////////////////////////////////////////////
> //////////
> 
> 	[ Richard] When using the WAI over EAP, the AP would 
> transport EAP packet 
> 
> 	(contains WAI) over Radius. 
> 
>    Also, Please check my last email: It compares the solutions of
>    the Radius Property extension with the WAI over EAP. 
>    The main advantage of WAI over EAP is to keep the loose coupling
>    between the AAA and the WAPI.
>    The reason is:
>   Radius server need not check things going on with WAPI. (EAP-WAI).
>   There is a standard interface  (EAP-SUCCESS or EAP-FAILURE)
>   to let Radius know the result of the authentication.
>   From the AAA server perspective, like the other 
> authentication methods  such as EAP- TLS,  there is no any 
> special handle required for EAP-WAI.
>  
[Joe] EAP-Success and EAP-Failure are not part of RADIUS. They are part
of EAP messages that are for the peer, which is the client being
authenticated.  RADIUS has an Access-Accept and Access-Reject messages
for informing the RADIUS client of its decision.  Your proposal does not
appear to be an authentication mechanism like EAP-TLS since it does not
communicate with the peer.  

Can you give an example of what you mean by loose coupling between AAA
and WAPI?  

>  [Dan] I do have a suggestion to fix this problem. Just get 
> rid of the "certificate authentication" exchange and have the 
> client validate the AP's certificate and the AP validate the 
> client's certificate.
> It is not necessary to have a central authority to approve of 
> certificates, that's the whole point in using certificates.
> ///////////////////////////////////////////////////////////////////
> [ Richard] Yes, your suggestion could work well without a a 
> central authority involved.
> While the current problem I try to resolve is: The WAPI 
> protocol already exist (it needs a central authority to 
> valide the certificate), to support (follow) it and enable it 
> work well under the AAA architecture, I brougt forward the 
> method of WAI over EAP. 
> To avoid the change of the station, and minimize the influnce 
> to the customers, the solution would only change the packet 
> between AP (authenticator) and AAA server.
> To achieve this objective and avoid the influnce to the AAA, 
> the AP should minic the station.
> For the WAPI protocol, please see the slide 7.
> 
[Joe] This is not the way EAP works currently.  EAP is a protocol that
involves the peer.  If you have the authenticator mimic the peer then it
is not EAP in its current form. 

> 
> 	
> 	
> 	 regards,
> 	
> 	 Dan.
> 	
> 
> 	On Mon, July 27, 2009 7:54 am, Richard wrote:
> 	> Hi, all:
> 	>
> 	> The link to the slide:
> 	> http://www.ietf.org/proceedings/75/slides/emu-10.ppt
> 	> Thanks for your comments in the EMU session.
> 	>
> 	> Yes, the Radius property extension could be one solution.
> 	> The problem to it is:
> 	> The Radius has to handle the WAPI packet (Certificate 
> authentication
> 	> response),
> 	> it would lead to the tight coupling between Radius 
> and WAPI (ASE).
> 	>
> 	> Compared to it, the EAP solution is simple and make 
> it loose coupling with
> 	> WAPI.
> 	> Radius server need not check things going on with 
> WAPI. (EAP-WAI).
> 	> There is a standard interface to let Radius to know the result
> 	> of authentication (EAP-SUCCESS or EAP-FAILURE).
> 	> From the AAA server perspective, there is no any 
> special for EAP-WAI
> 	>  to the other authentication methods such as EAP-TLS.
> 	> The loose coupling for EAP solution is a main 
> advantage to the Radius
> 	> extension
> 	> method.
> 	>
> 	> Yes, the EAP framework is to authenticate the station 
> (supplicant). I
> 	> guess
> 	> the
> 	> main reason is that most authentication methods are 
> to authenticate the
> 	> supplicant,
> 	> and the behavior of Authenticator is pass-through.
> 	> Now, WAPI is a use case of authenticating the 
> authenticator (the behavior
> 	> of
> 	> Authenticator
> 	>  is not Pass-through). And it may have more protocols 
> which have similar
> 	> behavior
> 	> (use cases) like the WAPI.
> 	> Could we allow the EAP method behavior like the WAI 
> over EAP instead of
> 	> forbidding it?
> 	>
> 	> Any way, the problem I am trying to resolve is to 
> reuse the AAA and
> 	> avoid the tight coupling between Radius and WAPI (ASE).
> 	>
> 	> Do you have any better solution to it?
> 	>
> 	> Regards
> 	> Richard
> 	
> 	> _______________________________________________
> 	> Emu mailing list
> 	> [email-masked]
> 	> https://www.ietf.org/mailman/listinfo/emu
> 	>
> 	
> 	
> 	
> 
> 
>

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 3 Aug 2009 16:23:00 -0700

> Sent: Monday, July 27, 2009 7:54 AM
> To: Joseph Salowey (jsalowey); [email-masked]
> Subject: If we use the Radius property extension
> 
> Hi, all:
>  
> The link to the slide:
> authentication response), it would lead to the tight coupling 
> between Radius and WAPI (ASE).
>  
> Compared to it, the EAP solution is simple and make it loose 
> coupling with WAPI.
> There is a standard interface to let Radius to know the 
> result of authentication (EAP-SUCCESS or EAP-FAILURE).
> From the AAA server perspective, there is no any special for 
> EAP-WAI  to the other authentication methods such as EAP-TLS.
> The loose coupling for EAP solution is a main advantage to 
> the Radius extension method. 
> 
[Joe] EAP-Success and EAP-Failure are for the Peer and not the RADIUS
client.  The RADIUS access-accept and access-reject are for the RADIUS
client.  

> (supplicant). I guess the main reason is that most 
> authentication methods are to authenticate the supplicant, 

[Joe] Correct.

> Now, WAPI is a use case of authenticating the authenticator 
> (the behavior of Authenticator  is not Pass-through). And it 
> may have more protocols which have similar behavior (use 
> cases) like the WAPI. 

[Joe] When the authenticator does not run in pass-through then the EAP
communication is only between the Peer and EAP-Authenticator, EAP is not
communicated to the AAA.  

> Could we allow the EAP method behavior like the WAI over EAP 
> instead of forbidding it?
>  
[Joe] Not without changing the EAP architecture.  

> Any way, the problem I am trying to resolve is to reuse the 
> AAA and avoid the tight coupling between Radius and WAPI (ASE).
>  
[Joe] You need to have a AAA server talk to a WAI service.  You need to
define some protocol or API to do this.  You would like EAP to be this
protocol, but this is not the appropriate use for EAP as it is bound to
the communication between the EAP peer and EAP authenticator.  You can
define a separate protocol that includes messages that indicates success
or fail clearly.  This protocol can be incorporated into RADIUS
attributes just as EAP can.