Re: [pcp] EAP retransmits and re-authentication

[Yoshihiro Ohba <[e-mail]>]

I believe Alper and Sam are discussing EAP re-authentication in the
context of RFC 3748 and RFC 5247 and not specifically in the context
of RFC 5296 (ERP).  Let's not confuse ourselves.

EAP re-authentication in the context of RFC 3748 and RFC 5247 is
supported by most known lower-layers, including 802.1X and PANA, for
re-keying lower layer SA.

While I agree that ERP is definitely not needed for PCP, but I think
unsupporting EAP re-authentication in the context of RFC 3748 and RFC
5247 is NOT a good idea, because it enables smooth migration from old
SA to new SA.  Without supporting EAP re-authentication in the context
of RFC 3748 and RFC 5247, communications disruptions can happen during
rekey, i.e., communication quality of PCP and data traffic controlled
by PCP can affect in our case.

Also, it seems that there is some desire to change PCP-specific
authentication design to be based on client-initiated request so that
it fits the PCP-base design.  This just shows that this is an issue
with the current design of PCP-specific authentication.  Regarding
client-initiated request support for EAP lower layer, I also have the
same doubt as Alper has.  Whether it works with acceptable complexity
really depends on detailed characteristics of the targeted lower
layer.  Showing examples of EAP-GSS and IKEv2 does not help for PCP.
I can say that EAP over DHCP that was rejected by IETF, one major
reason was that is was considered to be difficult to fit EAP into
DHCP's client-initiated request model (I forgot why it is difficult, I
suggest to read the entire email discussion in DHC WG on this).
Having said that I cannot really judge until and unless a complete
solution for the design change is shown.

I suggest not to spend too much time for justifying or promoting
re-invented designs which can easily contain flaws and disadvantages
that were already taken care of in the original design that
successfully went through critical evaluation by a large community (IETF).

Yoshihiro Ohba

(2012/09/20 21:48), Sam Hartman wrote:
> 
> I wanted to give the WG some final thoughts on the conversation Alper
> and I  have been having.
> This will probably be my last message on the topic as I think we're
> basically at the point of diminishing returns.
> 
>>>>>> "Alper" == Alper Yegin <[e-mail]
> g> writes:
> 
> On the topic of retransmits, we agree that under section 4.3 of RFC
> 3748, you can set the transmit timer to infinite.
> I think we agree that this moves retransmits from within the EAP layer
> to the EAP lower layer.
> 
> 
>      Alper>   When run over a reliable lower layer (e.g., EAP over
>      Alper> ISAKMP/TCP, as within [PIC]), the authenticator
>      Alper> retransmission timer SHOULD be set to an infinite value, so
>      Alper> that retransmissions do not occur at the EAP layer.
> 
> 
>      Alper> Only when run over a reliable EAP lower layer, the EAP layer
>      Alper> sets the timeout to infinity.  So, whether the rexmit is
>      Alper> handled by the EAP layer, or the EAP lower layer, the PCP
>      Alper> server will be sending retransmissions in your case.
> 
> It's actually fairly easy to move which side generates the
> retransmission once you move it into the lower layer.
> Note that the PCP server still needs to maintain the state of what EAP
> request to send, but whether to send that can be based on what the
> client sends.
> That is, if the PCP state machine works better with client-driven
> retransmits,
> we can achieve that.
> We do need authentication-session state in the server, and part of that
> state is the unacknowledged eap-request if there is one.
> 
> 
> With regard to re-authentication:
> 
>>>      Consider what happens in an AAA server. There, your EAP
>>> server cannot (and is not supposed to) handle retransmits.
>>> RADIUS at least is a lock-step protocol. Ignoring things like
>      Alper> COA,
> 
> 
>      Alper> Ah, "ignoring CoA". CoA is the RADIUS' tool to generate an
>      Alper> unsolicited message, more specifically for starting EAP
>   
> I'd like to draw the WG's attention to RFC 5176, which defines COA.
> Section 4 explicitly mentions that COA cannot be used for starting
> re-authentication.  Section 1.1 is an applicability statement explaining
> why COA is not standards-track because of security and semantic
> concerns.
> 
> As best I can tell only diameter has AAA support for re-authentication.
> So, I'd like to draw our attention to RFC 4005, section 3.3 which
> defines rules for diameter re-authentication.  That section explicitly
> calls out re-authentication must be supported *if the underlying service
> supports it*.  That is, re-authentication is OPTIONAL for a given
> service like PCP, but if a given PCP server supports re-authentication
> and diameter, then it needs to support re-authentication via diameter.
> Section 3 of RFC 4072 (diameter over eap) confirms the guidelines of RFC
> 4005 apply.
> 
> Re-authentication being optional is definitely consistent with my
> implementation experience.  I have no experience with diameter, but do
> have a lot of experience with EAP implementations that consider
> re-authentication optional.
> 
> 
> This is all great news for the PCP community.  We can choose the
> retransmission strategy that best meets the PCP implementations.  we can
> choose to support re-authentication if it is useful, or decline to
> support it if it is not.  If we don't choose to support
> re-authentication then we can avoid the complexity.
> _______________________________________________
> pcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcp
>