[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: New XAUTH draft

To: "'Stephane Beaulieu'" <sbeaulieu@TimeStep.com>, "'Scott G. Kelly'" <skelly@redcreek.com>
Subject: RE: New XAUTH draft
From: "Bernard Aboba" <aboba@internaut.com>
Date: Mon, 24 May 1999 06:26:22 -0700
Cc: <ipsec@lists.tislabs.com>, "'ipsra'" <ietf-ipsra@vpnc.org>
Importance: Normal
In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDFA9716B@exchange>
Reply-To: <aboba@internaut.com>
Sender: owner-ipsec@lists.tislabs.com

> Imagine a policy which permits any client to access a radius server
> behind the sgw, but limits all other access. 

According to RFC 2138, clients do not access RADIUS servers. This is 
not possible within the RADIUS protocol. Perhaps you mean that the 
client speaks EAP to the tunnel server, which then speaks RADIUS
to the RADIUS server?

>When a client wishes to access the protected net, it forms 
>a radius-only SA, and through this authenticates with the 
>radius server. 

This scenario makes no sense. Again, under RFC 2138, clients
do not interact with RADIUS servers. If this is really what
you have in mind (I think you mean EAP instead), can you explain
what the client is supposed to do with the RADIUS authorizations
that come back in the Access-Accept? What if the server sends
a Filter-ID attribute? Is this used to influence IPSEC filter
policy? Enforcement of security-related RADIUS attributes
on the client does not make sense.

References:

RE: New XAUTH draft

From: Stephane Beaulieu <sbeaulieu@TimeStep.com>

Prev by Date: RE: New XAUTH draft
Next by Date: I-D ACTION:draft-ietf-ipsec-ike-01.txt
Prev by thread: RE: New XAUTH draft
Next by thread: RE: New XAUTH draft
Index(es):
- Main
- Thread