Subject: [eap] Review of draft-adrangi-eap-network-discovery-01.txt

From: Bernard Aboba <[email-masked]>
Date: Fri, 16 Jul 2004 11:27:32 -0700 (PDT)

Comments on draft-adrangi-eap-network-discovery-01.txt:

In general, I'm confused as to whether this document is specifying a
general mechanism for providing hints relating to supported EAP-Response
NAIs, or a 3GPP-specific mechanism for network discovery.  If the former,
I'd suggest that the title be changed to "EAP Identity Discovery
Mechanism".  If the latter, I'd suggest that the title be changed to:

"3GPP Network Discovery Mechanism"

Whichever tack you are taking should be clearly indicated in the
Appendix.

Section 1 - Introduction

I think that in this section you want to present the general problem,
which is how an EAP server can provide a hint to the EAP peer as to what
identity is required in the EAP Response.

That problem can occur even where there is only one network available, but
the NAI provided is not one which the EAP server can recognize.  For
example, I roam to a guest network and because SSIDs are not unique,
confusion results and the EAP peer presents the wrong NAI.  While today it
is possible to send a notification telling the user that something has
gone wrong, wouldn't it be better if the problem could be fixed
automatically?

It just so  happens that this problem needs to be solved
for the purposes of network discovery, but I think that
introducing this early on muddies the waters.

For example, while one could argue that advertisement
of mediating networks is something that belongs in the
lower layer, providing a hint about the appropriate
EAP-Response is clearly an EAP function.

So I think this section needs to clearly articulate the
general problem or else the document becomes vulnerable
to the criticism that it represents a layer violation.

Personally, I'd prefer if this section stated up front
some basic aspects of NAIRealms, such as:

* It builds on the NAI Realm syntax specified in
RFC 2486bis;

* It provides a hint as to the NAI Realm that the
EAP Server is expecting, enabling improved
robustness;

* It is compatible with any EAP method;

* It is unsecured -- and therefore may not be
preferrable to secured identity selection mechanisms,
such as RFC 3770;

* It may enable additional credential disclosure attacks, although only if
insecure EAP methods are used;

Personally, I see mediating network discovery as only
one application of this specification and would prefer
that "Application" to be discussed later on, or even
moved to an Appendix.

Since the diagrams mention "AAA" I'm not even sure why
the RADIUS disclaimer is necessary.  You could just say
that "this mechanism is compatible with
either the RADIUS or Diameter protocol".

Section 2

Somewhere I think you need to describe how the functionality
in this specification affects behavior of [RFC3748] implementations,
before launching into the grammar.  Otherwise this is left to the
imagination which is a bad thing given that 3GPP has requested a
review of compatibility with [RFC3748].

I'd suggest that you need a section prior to the existing Section 2.

Here is what Section 5.1 of [RFC3748] says:

"     The Identity Type is used to query the identity of the peer.
      Generally, the authenticator will issue this as the initial
      Request.  An optional displayable message MAY be included to
      prompt the peer in the case where there is an expectation of
      interaction with a user.  A Response of Type 1 (Identity) SHOULD
      be sent in Response to a Request with a Type of 1 (Identity).

      Some EAP implementations piggy-back various options into the
      Identity Request after a NUL-character.  By default, an EAP
      implementation SHOULD NOT assume that an Identity Request or
      Response can be larger than 1020 octets."

and later:

"  Implementation Note: The peer MAY obtain the Identity via user input.
   It is suggested that the authenticator retry the Identity Request in
   the case of an invalid Identity or authentication failure to allow
   for potential typos on the part of the user.  It is suggested that
   the Identity Request be retried a minimum of 3 times before
   terminating the authentication.  The Notification Request MAY be used
   to indicate an invalid authentication attempt prior to transmitting a
   new Identity Request (optionally, the failure MAY be indicated within
   the message of the new Identity Request itself)."

Given the above, you need to describe the following:

* How the specification interacts with other existing piggy-back
practices.  As I understand it, the grammar is intentionally made
compatible with those existing extensions, but you should say that.

* How retry behaviors are affected.  How are endless loops prevented?
For example, is the [RFC3748] behavior unmodified?

* How errors are handled.  Is Notification used to inform the user
that something has gone wrong?  Or do things just break without
notice?

* How the proposed functionality works with the minimum
EAP MTU size of 1020 octets.  Note that since the functionality
in question is already used for other purposes, you can't necessarily
assume that you have the entire EAP Request to yourself.  How
many NAIRealms can fit within what might be less than 1020 octets?
Is this enough?

Sections 3 and 4 - These sections seem to belong with Appendix A,
especially since that Appendix already references them.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Adrangi, Farid" <[email-masked]>
Date: Mon, 19 Jul 2004 17:03:21 -0700

Hi Bernard,
Thanks for another round of comments and helping us in improving the
draft - is very much appreciated!  Please see my comments inline.
BR,
Farid

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Bernard Aboba
> Sent: Friday, July 16, 2004 11:28 AM
> To: [email-masked]
> Subject: [eap] Review of draft-adrangi-eap-network-discovery-01.txt
> 
> 
> general mechanism for providing hints relating to supported 
> EAP-Response NAIs, or a 3GPP-specific mechanism for network discovery.

> If the former,

The main motivation of the draft is to solve 3GPP VPLMN discovery &
selection. However, the proposed solution can be applied to any other
mediating network types and therefore I think the current title ("
Mediating Network Discovery in the Extensible Authentication
Protocol(EAP)") is appropriate.  Furthermore, I believe the title and
the problem description is consistent with what described in the netselc
problem statement draft - if so, I don't really understand the source of
the confusion here.  Please read more on this topic below.

> which is how an EAP server can provide a hint to the EAP peer as to 
> what identity is required in the EAP Response.
> 

First, the intent here is *NOT* to have EAP server to provide this hint
- the hint comes from the AP or the access network AAA server.  The
problem statement draft (draft-ietf-eap-netsel-problem-00.txt) describes
four distinct problems: 1) Access Network selection  2) Credential
Selection 3) Mediating Network Selection 4) Payload routing.  Our focus
here is the problem #3 -- specifically, on the mediating network
*discovery* aspect of it; the selection part is addressed by 2486bis.
Do you see any inconsistency here w.r.t to the problem statement draft?

> gone wrong, wouldn't it be better if the problem could be fixed

Valid problem.  But, I think this is not related to mediating network
discovery rather it is a credential selection problem.  If so, I would
prefer to discuss this in a separated draft if you are okay with it?  

> introducing this early on muddies the waters.

For the purpose of *Mediating Network Discovery*!

> EAP-Response is clearly an EAP function.

We discussed other alternatives (e.g., lower layers) with pros and cons
of each in the last IETF (presented by Jari), and there was a consensus
that we need an EAP-based solution (at a minimum as a short-term
solution).  We also decided to have the draft to focus on describing how
the problem can be solved using EAP, and not going into describing other
alternatives that can be implemented today or enabled by future
enhancements/extensions from IEEE.  FYI - in the previous versions of
the draft, we had a section describing other alternatives with pros and
cons of each, and the rationale for the proposed EAP-base method.  

> to the criticism that it represents a layer violation.
 
I still don't understand why you think the problem is not clear.  And so
far, I haven't seen any criticism that the proposed solution represents
a layer violation.  How can this  be a layer violation if you believe
that
the selection can be done using NAI decoration (as specified in your
draft 2486bis)?

> * It builds on the NAI Realm syntax specified in

This is mentioned in the introduction section (see the quote below).
But, we can put more emphasis on it if you want?

"
  ...
   Section 2.7 of [2486bis] discusses the conditions upon which NAIs can
be
   used to affect AAA routing, i.e., problem 3 above.  Problems 1 and 2
   are discussed in this document
"

> EAP Server is expecting, enabling improved

We are talking about AAA routing here -- this is about providing a hint
(in form of NAI realms) to the EAP peer by an AP or access network AAA
server.  What is the role of "EAP server" in this context?

> * It is compatible with any EAP method;

Ok.  

> preferable to secured identity selection mechanisms,
> such as RFC 3770;
> 

The fact that the mediating network discovery process is insecure is
mentioned in the security section of the draft. This draft has decoupled
authentication from the mediating network discovery process. This
decoupling is especially useful for networks like the 3GPP where SIM is
used for authentication once a mediating network is discovered /
selected.   In conclusion, IMO, the comparison with RFC 3770 will not
make sense here and therefore it should not be discussed in this draft.
Agree?
 
> insecure EAP methods are used;

I do not see how this will be true for 3GPP networks for example. See my
comments to your previous question.

> that "Application" to be discussed later on, or even

IMO, the draft is clear on usage model for mediating network discovery
and emphasizes that it should not be extended to solve other problems. 

The draft describes a well identified and a specific problem with a
narrow scope that requires an immediate solution in our industry. It
maps to one of the four identified areas in the problem statement draft
and I believe we should not try to extend it for solving any other more
general problems.

> either the RADIUS or Diameter protocol".

This is what draft says:

"
RADIUS [2] protocol has been assumed for AAA mediation between the
access network and the home network
although Diameter [3] could also be used instead of RADIUS without
introducing significant architectural differences.
"

The reason for this is to give more specific and clear examples when we
describe implementation notes or the delivery option mechanisms in the
appendix.

> compatible with those existing extensions, but you should say that.

Are you referring to other implementation that already use the
EAP-Identity type-data field (the space after the null) in proprietary
manner?  Please clarify.  

> For example, is the [RFC3748] behavior unmodified?

Yes.  We will add a text that the proposed solution is fully compliant
with RFC 3748.   Unless you see some inconsistency here?

> that something has gone wrong?  Or do things just break without
Error handling is done according to RFC 3748.

> many NAIRealms can fit within what might be less than 1020 octets?

We can provide general guidelines on it e.g. from 3GPP in the
implementation considerations section of the draft. A Realm in 3GPP will
be [email-masked]. With maximum lengths for mnc and mcc to be 3
characters, the realm will be 23 characters followed by ";". This would
provide space for roughly 42 mediating networks in 1020 octets. We
Believe this to be quite enough especially when this information is only
considered a hint and the serving network is not required to provide an
exhaustive list of mediating networks.  Please note that in 3GPP we are
working to convey the VPLMN name in less number of characters -- for
example, just mnc.mcc.  This means that the space can utilized much more
efficiently. So how about the following text to be added in Section 4?

"Because of space constraints (imposed by the link MTU) in EAP-Identity
Request message, the maximum size of mediating networks related
information is roughly limited to 1020 octets. In the case of 3GPP for
example, a realm will be [email-masked]. With maximum lengths
for mnc and mcc to be 3 characters, the realm will be 23 characters
followed by ";". This would provide space for carrying information on 42
mediating networks in 1020 octets. Optimization of 3GPP mediating
network information carried in EAP-Identity Request message is possible
by simply providing only the mnc and mcc part of the realm, i.e., mncmcc
followed by a ";".   This optimization will utilize the space much more
efficiently, and it allows information on more mediating networks to be
conveyed in the EAP-Identity Request."

> especially since that Appendix already references them.

This is more like organization issue -- we can discuss it once we are
done with closing all technical issues.

---

From: "Adrangi, Farid" <[email-masked]>
Date: Mon, 26 Jul 2004 14:48:16 -0700

Hi Bernard,
Thanks for your reply. Please see my comments inline.
BR,
Farid

> > - the hint comes from the AP or the access network AAA server.
> 
> The EAP Server is defined as the endpoint initiating EAP.
> How can the EAP server not be involved in the conversation?
> 

EAP server will be involved eventually.  But, the AAA routing happens
before the EAP server comes into the picture.  For example, who sends
the initial EAP-Identity Request when the WLAN client associates to the
AP?  Answer: the AP for the access network AAA proxy.  If so, then, the
WLAN client responds with the EAP-Identity Response which may contain a
decorated NAI.  The AAA proxy uses the decorated NAI to determine how to
route the AAA packet which also encapsulates EAP.  So, the AAA routing
happens before the EAP server becomes involved.  Please let me know if I
am missing your point here?

> > prefer to discuss this in a separated draft if you are okay
> with that?
> 
> My original understanding was that the hints were given in
> the form of an NAI Realm as defined in RFC 2486bis, providing 
> information on the NAI Realm required in the EAP-Response/Identity.
> 
Correct.

> For example, say an EAP peer receives an EAP-Request with
> NAIRealm=foo.com.
> 
> The peer has potential identities for [email-masked], and
> [email-masked].  Based on the hint, my understanding was that 
> the peer would select [email-masked].  Is this correct?
> 

Here are the assumption for the problem that we are solving:

- The user has one identity ([email-masked]).
- The access network does not have a direct relationship with
example.com - i.e., it cannot forward the AAA packet to example.com
directly.
- the access network has roaming relationship with the foo.com (the
intermediary)
- example.com has roaming relationship with foo.com (the intermediary)
- Using the proposed solution and 2486bis, the user forms a decorated
NAI : [email-masked]. to influence the routing of AAA packet
through foo.com to example.com.

I would like to treat the scenario that you described (i.e., multiple
identities; identity/credential selection) as a separate problem -- it
is also treated as such in the problem statement draft.

> Of course there are other cases too, such as where "foo.com" 
> is advertised in the NAIRealm and the peer has 
> "[email-masked]" and therefore might send a decorated NAI 
> ([email-masked]).  But it seems like the basic case 
> should also work.
> 
> Is it still true that the "NAIRealm" grammar references RFC 
> 2486bis? It sounds like there is a "short form" grammar also 
> under discussion.
> 

The draft clearly refers to RFC 2486bis for the NAI grammer and the NAI
decoration syntax - please let's not confuse the grammer "NAIRealm"
attribute (defined in the EAP-discovery draft) and the NAI grammer
(which include NAI realm) defined in 2486bis.  If someone wants to
change the NAI grammar or use a different syntax for NAI decoration,
then he/she should convince the authors of RFC 2486bis for that change!
The grammer for "NAIRealm" attribute is defined to express the MN
information -- example:

NAIRealm=anyisp1.com;anyisp2.org;mnc.mcc  -- Where the syntax for
anyisp.com and mnc.mcc is compliant with the syntax of NAI realm defined
in the 2486bis (page 5).

> Yes.  Those implementations will continue to exist, so they 
> can't be outlawed.
> 

Agree.  First, this should not be a problem if MN information is
conveyed on a subsequent EAP-Identity Request -- and that's the delivery
option the draft recommends.  In other cases, "NAIRealm" attribute
should coexist with other proprietary stuff placed after the NULL
character in the EAP-Identity Request.  There are two possibilities:

1) "NAIRealm" attribute is always placed last after the proprietary
stuff.  So, the client searches for the keyword "NAIReal" and consumes
the information after that as the MN information. Note that the
assumption here is that the proprietary information does not contain the
"NAIRealm" followed by "=" keyword.
2) "NAIRealm" can be placed anywhere after the NULL character.  Extend
the grammar to indicate the end of NAIRealm attribute.

I like the first option -- what is your advice?   I will update the
draft based on that.

> What's needed is some advice on how to avoid problems.  For 
> example, EAP servers should give up after N (n=3?) attempts, etc.
> 

Ok.  I need to double check RFC 3748 -- my understanding was that we use
whatever is recommended in RFC 3748 for these problems -- for example :
retries.

> There is no general error handling facility in EAP.  Are you 
> referring to a Notification-Request?
> 
Yes.
> > example, just mnc.mcc.  This means that the space can utilized much 
> > more efficiently.
> 
> This implies a change to the grammar, no?  Wouldn't this make 
> the NAIRealms incompatible with the NAI Realm grammar in RFC 2486bis?

It should not.  My understanding is that mnc.mcc is a valid realm
according to 2486bis - no?  

> 
> I think if you are going to use a different grammar, then you 
> probably also need to indicate this somehow, perhaps with a 
> different keyword. Note that this also changes the scope of 
> the draft since now it is no longer a general facility for 
> realm hints, but one which is 3GPP specific.
> 
> 
> 

We will *NOT* use a different grammar other than NAI realm defined in
2486bis.  Being compliant to RFC 3748 and RFC 2486 are the key
requirements for us.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap