Subject: [abfab] gss-eap: eap identity?

From: Sam Hartman <[email-masked]>
Date: Tue, 06 Mar 2012 16:24:03 -0500

Hi.

we had a long discussion on the list and in the meeting about whether we
want to continue wasting a round trip on  eap request/identity or
whether we want to introduce a new subtoken type to carry the identity
from the initiator to the acceptor.

If I were making a consensus call I'd say we were going to drop the
round trip and add the subtoken.  However it was not entirely clear and
I'd sure appreciate any comments from the chairs or others.

---

From: Josh Howlett <[email-masked]>
Date: Tue, 6 Mar 2012 21:53:03 +0000

>I'd sure appreciate any comments from the chairs or others.

My recollection is that there was a fair amount of ambivalence around this
point, myself included. If I had to come off the fence I would prefer to
avoid a special-case for the sake of a single trip, but that's basically
an argument from aesthetics that I admit isn't hugely compelling.

Josh.

Janet is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

---

From: Luke Howard <[email-masked]>
Date: Wed, 7 Mar 2012 12:08:52 +1100

> an argument from aesthetics that I admit isn't hugely compelling.

Right, I had the same feeling as Josh.

-- Luke

---

From: Klaas Wierenga <[email-masked]>
Date: Wed, 07 Mar 2012 09:45:46 +0100

On 3/6/12 10:24 PM, Sam Hartman wrote:

Hi Sam,

> we had a long discussion on the list and in the meeting about
> whether we want to continue wasting a round trip on  eap
> request/identity or whether we want to introduce a new subtoken
> type to carry the identity from the initiator to the acceptor.
> 
> If I were making a consensus call I'd say we were going to drop
> the round trip and add the subtoken.  However it was not entirely
> clear and I'd sure appreciate any comments from the chairs or
> others.

As an individual: If I had to make a judgment call I would argue that
this extra round trip is not such a big deal compared to introducing a
new special case. It is my understanding that this exchange happens
once, when the application is accessed. Compared to using EAP for
network access where potentially a high frequency of reauthentications
need to take place I don't think this is a big deal. So I'd be happy
to sacrifice this one extra round trip for generality.

As a chair: Perhaps we need to make a formal consensus call, don't you
think?

Klaas

---

From: Sam Hartman <[email-masked]>
Date: Wed, 07 Mar 2012 09:46:42 -0500

Speaking as an individual.
I don't look forward to making changes to EAP identity handling now and
I definitely don't look forward to implementing the code for it.

I think this is a change we can make later.  I do think we'll have to
make it later.  This saves a round trip and throughout the IETF we've
generally found that saving round trips in authentication is
important. This is only a round trip when you access an application but
for some important classes of application you access them very very
frequently. For example for Kerberos used with HTTP we'd seen thousands
of authentications a second for a single web page. (Without fast
reauthentication of some kind, GSS-EAP will not be suitable for that
deployment. It stretches Kerberos a lot.)

So I think we'll end up supporting this long-term.
I think we can add support later.

I think the spec and implementation would be cleaner if we added support
now. Currently the EAP identity is more of a special case than I think
it will end up. Currently, we have EAP traffic both in the initial state
and in the authenticate state. Also, a passthrough authenticator needs
to synthesize an identity request. We could get rid of both of those if
we had an identity subtoken.

However we clearly don't have consensus to make the change (I'm really
glad I asked). Building that consensus would take time, getting the
change right and implemented would take time.

I'd rather just do this in a future extension document if I'm right that
we end up needing it.  I think the result will be slightly more ugly,
but it would be nice to get done and last call our core specs.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 7 Mar 2012 16:41:24 +0100

Hi Sam:

From what I recall, I suggested to move to the subtoken option because synthesizing an EAP response/id was not a good idea. 

The reasons were explained here http://www.ietf.org/mail-archive/web/abfab/current/msg00947.html

Nevertheless I am still wondering what is the benefit. Let me explain. Fast re-authentication is generally important but we are just saving a round trip between initiator and acceptor, which are not too much in comparison with the number of messages involved during a whole EAP authentication and the travel the messages have to do all the way to the home AAA/EAP server. So basically I believe reducing that part does not help too much if we do not reduce the real critic parts as the number of EAP messages or the fact they have to reach the home AAA/EAP server.

Not only that. I also made some additional comments about some situation that may happen, but I believe there were not any comments after my e-mail. My last e-mail was in

http://www.ietf.org/mail-archive/web/abfab/current/msg00950.html

But let me paste what I wrote:

"Definitely, designing a subtoken seems the most standard way of defining this optimization. Nevertheless, we may need to think about something I just realized. It may happen that when the acceptor sends the EAP-Start in the RADIUS Access-Request that the RADIUS EAP/AAA server decides to start the EAP request/identity instead the first EAP request of the chosen EAP method. The reason is the text about that RFC 3579 I pasted in my previous e-mail where it is said:

"The RADIUS server will
  typically respond with an Access-Challenge containing EAP-Message
  attribute(s) encapsulating an EAP-Request/Identity (Type 1).
  However, an EAP-Request for an authentication method (Type 4 or
  greater) can also be sent by the server."

It means that RADIUS EAP/AAA server implementation is not obligated (there is no MUST in the text) to start an EAP method instead of sending an EAP request/identity. This means that RADIUS EAP/AAA should be correctly configured to allow this optimization. Otherwise, the RADIUS EAP/AAA server will send the EAP request/identity that has to travel all the way to the authenticator. 

Although the solution does not violate any standard, in certain cases it may not help to achieve the optimization if the home EAP/AAA is not configured to select directly the EAP method for that peer. Even I would say that it is more problematic than sending the EAP request/identity from the authenticator (The EAP request/identity sent from the home EAP/AAA will add more latency and the same number of messages than the current not optimized case).

So the question would be : can we be sure that all home EAP/AAA servers will act to allow the optimization?"

NOTE: If the subtoken carries the same identity as it should be included in the EAP response/id, it may work. However, I am not completely sure what will be the default behavior of existing RADIUS servers when they receive a User-Name without any EAP packet or with the "EAP-Start" packet. Potentially, it seems they may initiate EAP Request/Id in some cases. It is for sure that RADIUS experts may provide some good insight about it.

Best regards.

El 06/03/2012, a las 22:24, Sam Hartman escribió:

> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Sam Hartman <[email-masked]>
Date: Wed, 07 Mar 2012 11:52:52 -0500

>>>>> "Rafa" == Rafa Marin Lopez <[email-masked]> writes:

    Rafa> Hi Sam: From what I recall, I suggested to move to the
    Rafa> subtoken option because synthesizing an EAP response/id was
    Rafa> not a good idea.

    Rafa> The reasons were explained here
    Rafa> http://www.ietf.org/mail-archive/web/abfab/current/msg00947.html

Right.
I think we all agree with you and appreciate that input.

    Rafa> Nevertheless I am still wondering what is the benefit. Let me
    Rafa> explain. Fast re-authentication is generally important but we
    Rafa> are just saving a round trip between initiator and acceptor,
    Rafa> which are not too much in comparison with the number of
    Rafa> messages involved during a whole EAP authentication and the
    Rafa> travel the messages have to do all the way to the home AAA/EAP
    Rafa> server. So basically I believe reducing that part does not
    Rafa> help too much if we do not reduce the real critic parts as the
    Rafa> number of EAP messages or the fact they have to reach the home
    Rafa> AAA/EAP server.

You may well be right. I had not fully thought this through.
It sounds like you'd be happy holding off on this change if we ever make
it.

When we are next in person I'd like to discuss this sort of optimization
with you in more detail.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 12 Mar 2012 10:39:42 +0100

> It sounds like you'd be happy holding off on this change if we ever make

I believe it would be interesting to further analyze the general problem, perhaps defining a problem statement and the requirements for a fast re-authentication procedure in ABFAB. Then, we could move to the solution space. I think this is an interesting topic.

> When we are next in person I'd like to discuss this sort of optimization

Sure.

Many thanks.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 12 Mar 2012 08:33:24 -0400

>I believe it would be interesting to further analyze the general problem, perhaps defining a problem statement and the requirements for a fast re-authentication procedure in ABFAB. Then, we could mo…

I'm delighted to hear you're interested the fast reauth problem; I think
it would be great to get more input into that process. I am frustrated
when people propose a formal problem statement/requirements draft. My
experience has been that these document take around a year to work
through.  How about we have a couple of brainstorming sessions and
possibly a call or two to collect input on requirements from interested
parties? I think that will capture as much value as a requirement
document with much less frustration and delay.

--Sam

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Mon, 12 Mar 2012 13:38:21 +0100

> document with much less frustration and delay.

+1
--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 12 Mar 2012 14:17:41 +0100

Yeah, that is also fine with me.