Subject: [eap] Re: Question about proiper incrementing of EAP-Id

From: [email-masked] (Bernard Aboba)
Date: Fri, 21 Mar 2003 21:15:51 -0800 (PST)

> Clients                           NAS                          RADIUS
>
>       <== REQ/IDENT  id:46  Client#1
>       <== REQ/IDENT  id:47  Client#2
>       <== REQ/IDENT  id:48  Client#3
>       Client#2 id:47  RESP/IDENT ==>
>                                          id:47  RESP/IDENT ==>
>                                         <== REQ/MD5-CHALLENGE id:48
>       <== REQ/MD5-CHALLENGE id:48 Client#2
>       Client#1 id:46  RESP/IDENT ==>
>                                          id:46  RESP/IDENT ==>
>                                         <== REQ/MD5-CHALLENGE id:47
>       <== REQ/MD5-CHALLENGE id:47 Client#1
>       Client#3 id:48  RESP/IDENT ==>
>                                          id:48  RESP/IDENT ==>
>                                        <== REJECT Client#3

It looks to me like the NAS behavior is perfectly legal -- it can choose
any Identifier that it wants at the beginning of a session, since the
Identifier space isn't shared between sessions. The problem is that the
RADIUS server isn't providing a unique Identifier space between sessions,
so it is broken.

We probably need to add text to RFC 2869bis to make it clear that the
RADIUS server is behaving inappropriately. How about this:

"In EAP, each session (as defined by combination of NAS-Port and NAS
identification attributes such as NAS-Identifier,
NAS-IPv6-Address or NAS-IPv4-Address) has its
own unique EAP Identifier space. RADIUS server implementations MUST
be able to distinguish between EAP Responses with the same
Identifier but existing with distinct sessions."

> Is the NAS and RADIUS server generating REQ/RESOP w/ proper incrementing
> of the eap-id?

Yes, I believe both the NAS and RADIUS server are behaving legally.

> In 2284bis-01m , it says the Identifier space unique to each "session".
> What determines
> a "session". How is this applyed over to EAP-over-RADIUS? Where is this
> defined?

At any given point in time, an authentication session can be identified by
the combination of NAS-Port and NAS-Identifier/NAS-IPv6-Address/NAS-IPv4-Address.
Over time, sessions are uniquely identified by NAS identification
attributes and the Acct-Session-Id.

---

From: [email-masked] (Bernard Aboba)
Date: Fri, 21 Mar 2003 21:22:54 -0800 (PST)

> Hi to all,
> I'm a people of the IPsec WG. In these days we are discussing about some
> issues about EAP, which is going to be including in IKEv2. The main
> problem we have is this:
>
> Does the autheticator need to know the peer's identity before sending an
> EAP(Request,MD5)? Or we can send that EAP message without knowing the
> initiator identity? Is it possible a scenario like this?

In the flow below you are ommitting the EAP-Request/Identity, and
always sending an EAP MD5-Challenge. This implies that you know that
MD5 is the appropriate method for all users. Given that the MD5-Challenge
method cannot be cryptographically bound to IKEv2, this may not be a wise
choice.

Also, the EAP-Request/Identity can contain a hint as to what the
EAP-Response/Identity should be. Since the client might select its
credential based on that hint, it is possible that the client may not be
able to respond correctly. Also, is it always clear that the IKE IDi and
the EAP Response/Identity are necessarily the same? It seems like you are
assuming this.

>
> 	Peer					Authenticator
>         ------			  	       ---------------
> 				    <--	      EAP(Request,MD5)
>         IDi, EAP(Response,MD5)       -->
> 				    <--	      EAP(Success/Failure)
>
> EAP messages are encapsulated in IKEv2, and IDi is carried by a special
> IKEv2 payload type (Identity).
> Will this solution work?

I don't think so. What do other people think?

---

From: [email-masked] (Jo Hermans)
Date: Mon, 24 Mar 2003 10:58:24 +0100

>attributes and the Acct-Session-Id.
I agree. But keep in mind that Nas-Port (or Nas-Port-Id) isn't unique ! 
Several RADIUS RAN's are using NAS-port's that are shared between 
different sessions, which creates serious problems in stateful proxy 
servers. RFC2865 never mentioned what a "port" really is, just that it's 
"in its sense of a physical connection". Some RAN's take that quite 
literally, and return the ATM-VCI or even the number of the E1 board.

As Bernard said, we really need to use acct-session-id (combined with 
the nas-ipaddress/nas-identifier to make it globally unique) to identify 
a session. But since that attribute isn't present in access-requests ... 
Luckily, several RAN's can be configured to return them anyway.

In my application, I'm using [nas-ipaddress + nas-port + username + 
callerid] as the identifier for the session. This works so far, even 
when the nas-ipaddress was bogus (as we've experienced in some networks).

-- 
Jo Hermans

There are 10 types of people in this world, those who can count in binary and those who can't.