Hi Yoav,
First of all, IDi is not sent in response to an EAP Identity Request.
Every NAS will, when it comes time to initiate EAP authentication,
request an identity. That's how EAP works. The IKEv2 responder "knows"
to send an EAP Identity Request because the IKEv2 initiator has
indicated it
Hi.
This is an interesting subject, and perhaps could be a good candidate for
discussion at Anaheim. However, from the narrow perspective of a VPN vendor, I
don't think this issue is very complicated:
- In the first IKE_AUTH request the initiator provides *an* identity. This
could be something
Hi Raj,
On Wed, February 10, 2010 2:30 am, Raj Singh wrote:
> On Wed, Feb 10, 2010 at 3:44 PM, Alper Yegin
> wrote:
>> In other uses of AAA (such as with WiFi, WiMAX, 3GPP2, etc.) I know that
>> the
>> subscriber ID is hidden from the NAS. There are even specific methods
>> deployed for that
Hi Alper,
On Wed, February 10, 2010 2:14 am, Alper Yegin wrote:
> Dan,
>
>> Hi Alper,
>>
>> In that case there is no standard way for the AAA server to inform
>> the
>> IKEv2 responder of this "policy" that it needs to enforce. So that
>> sounds
>> unworkable.
>
> I guess it can be specifie
Hi all.
Again we have some more issues:
Issue #147 - Allowing limited retransmission of one-way IKE messages
Either in 2.1 or in 1.5 we should say something about allowing limited
retransmission of the rare one-way IKE messages
At 12:14 PM +0200 2/10/10, Alper Yegin wrote:
Dan,
Hi Alper,
In that case there is no standard way for the AAA server to inform
the
IKEv2 responder of this "policy" that it needs to enforce. So that
sounds
unworkable.
I guess it can be specified.
The IKEv2 responder already ha
On Wed, Feb 10, 2010 at 3:44 PM, Alper Yegin wrote:
> Dan,
>
> > Hi Alper,
> >
> > In that case there is no standard way for the AAA server to inform
> > the
> > IKEv2 responder of this "policy" that it needs to enforce. So that
> > sounds
> > unworkable.
>
> I guess it can be specified.
>
>
Dan,
> Hi Alper,
>
> In that case there is no standard way for the AAA server to inform
> the
> IKEv2 responder of this "policy" that it needs to enforce. So that
> sounds
> unworkable.
I guess it can be specified.
> The IKEv2 responder already has the mechanisms in place to enforce a
> p
