Subject: Re: [Pana] Removal of the Handshake Phase

From: Jari Arkko <[email-masked]>
Date: Tue, 03 Oct 2006 17:26:40 +0300

Conte about revising the last two sentences of the paragraph 
> something like:
>
> When the PaC is pre-configured with ISP information, it may choose an
> ISP even when there is no ISP-Information AVP contained in the
> PANA-Start-Request message.  In this case, the choice is communicated
> to the PAA by containing an ISP-Information AVP in the
> PANA-Start-Answer message.
>
>   
>> The next paragraph helps a little in trying to understand what "convey" 
>> means. I think it means that if the ISP information AVP doesn't exist, 
>> EAP can do the network selection within a method:
>>
>>     
>>>   In the absence of an ISP explicitly selected and conveyed by the PaC,
>>>   ISP selection is typically performed based on the client identifier
>>>   (e.g., using the realm portion of an NAI carried in EAP method).  A
>>>   backend AAA protocol (e.g., RADIUS) will run between the AAA client
>>>   on the PAA and a AAA server in the selected ISP domain.
>>>  
>>>       
>> Which suggests that EAP can do the network selection, but gets into 
>> specifics that are probably better left outside of this document.
>>     
>
> I think we can remove the above paragraph on NAI-based network
> selection.
>
>   
>> Finally, this same section refers to RFC 4284 in its final paragraph, 
>> which seems to be yet another way to do network selection inside EAP 
>> (or, is this the same as referred to in the above paragraph?).
>>
>> This section presents far too many ways to do the same thing, and 
>> without enough detail for an implementor to know what to do. This 
>> section either needs work to define the *PANA* way to do this (with 
>> normative language, preferably MUSTs or SHOULDs, referring to protocol 
>> constructs specific to PANA),  in the absence of an EAP method that does 
>> network selection. Or, network selection should be simply removed - it 
>> seems EAP does this anyway, so you could perhaps avoid this problem 
>> altogether by just letting EAP handle it (again, "Less is More").
>>     
>
> The functionality provided by PANA and provided by RFC 4284 is
> different.  RFC 4284 does not allow an EAP peer to choose an ISP using
> a single NAI such as [email-masked].  Also RFC 4284 has a limitation
> in number of ISPs contained in EAP message due to EAP MTU.  I am
> wondering if we can remove refernece to RFC 4284 from the PANA
> specification.
>
> Yoshihiro Ohba
>
>
>   
>> - Mark
>>
>>
>>
>>
>> _______________________________________________
>> Pana mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/pana
>>     
>
> _______________________________________________
> Pana mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pana
>
>
>   

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Jari Arkko <[email-masked]>
Date: Tue, 03 Oct 2006 17:26:40 +0300

Yoshihiro,
> Since PaC and PAA may be communicating over multiple IP hops (and thus
> PAA is exposed to attackers in the Internet in general), it is
> important from security perspective to support stateless operation
> until rechability of the PaC from the PAA is verified as much as
> possible.
>
> Speaking of EAP layer state, I know of an existing EAP authenticator
> state machine implementation that requires more than 500 bytes of
> memory allocation per EAP session.
I'm not sure this is a major problem. I agree that we need to
verify that the client is a real entity before engaging in a
costly exchange. But the first EAP message is EAP Identity
Request, and it comes from the PAA, not from the AAA.
There's really very little need for state at that time other
than the ID value from the EAP packet, but even this could
be either static or somehow related to the Cookie value. So
I think implementations can be built to be stateless even
if you send the first EAP message at an early stage.

--Jari

nt-Type: text/plain; charset=ISO-2022-JP
Cc: Mark Townsley <[email-masked]>, [email-masked]

Yoshihiro,
> Since PaC and PAA may be communicating over multiple IP hops (and thus
> PAA is exposed to attackers in the Internet in general), it is
> important from security perspective to support stateless operation
> until rechability of the PaC from the PAA is verified as much as
> possible.
>
> Speaking of EAP layer state, I know of an existing EAP authenticator
> state machine implementation that requires more than 500 bytes of
> memory allocation per EAP session.
I'm not sure this is a major problem. I agree that we need to
verify that the client is a real entity before engaging in a
costly exchange. But the first EAP message is EAP Identity
Request, and it comes from the PAA, not from the AAA.
There's really very little need for state at that time other
than the ID value from the EAP packet, but even this could
be either static or somehow related to the Cookie value. So
I think implementations can be built to be stateless even
if you send the first EAP message at an early stage.

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 3 Oct 2006 16:58:09 -0400

Hi Jari,

I agree with you that a more optimized implementation can consume less
amount of memory allocation even when a cookie and the first EAP
request are carried in the handshake phase messages.  In fact, the
specification does not prohibit the operation:

"
   The initial EAP Request message MAY be optionally carried by the
   PANA-Start-Request (as opposed to by a later PANA-Auth-Request)
   message in order to reduce the number of round-trips.  This
   optimization SHOULD NOT be used if the PAA is desired to be stateless
   in the handshake phase since transmission of an EAP Request message
   creates a state at EAP layer.  See [RFC4137] for more information on
   the EAP state machine and the allocation of state information in the
   respective protocol steps.
"

Or are you suggesting to *always* carry EAP message in the handshake
phase messages regardless of L-flag?

Regards,
Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Wed, 04 Oct 2006 08:12:42 +0300

> phase messages regardless of L-flag?
That's what I was asking about: can we simplify this
by having just one mode and no flag?

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 4 Oct 2006 18:03:15 -0400

> by having just one mode and no flag?

If you are suggesting to have only stateful mode with always carrying
EAP message (and no cookie), then an attacker that intercept PSR can
blindly send PSA without even parsing PSR, which is not good.

If you are suggesting to have only stateless mode with always carrying
cookie and EAP message, then a remaining issue would be that PAA needs
to retransmit EAP Request while it has sent a cookie, which does not
make sense to me.

Yoshihiro Ohba