eap Mailing List: RE: Review of draft-adrangi-eap-network-discovery-01.txt

[Adrangi, Farid (farid.adrangi]

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: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] On 
> Behalf
> Of Bernard Aboba
> Sent: Friday, July 16, 2004 11:28 AM
> To: eap [at] frascone.com
> Subject: [eap] Review of draft-adrangi-eap-network-discovery-01.txt
> 
> 
> 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"
> 

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.

> 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.
> 

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?

> 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?
> 

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?  


> 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 the purpose of *Mediating Network Discovery*!

> 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.
> 

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.  


> 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.
> 
 
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)?

> 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;
> 

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
"

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

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.  

> 
> * It is unsecured -- and therefore may not be
> 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?
 
> * It may enable additional credential disclosure attacks, 
> although only if
> 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.

> 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.
> 

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.

> 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".
> 

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.

> 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.
> 

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.  

> * How retry behaviors are affected.  How are endless loops prevented?
> 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?

> * How errors are handled.  Is Notification used to inform the user
> that something has gone wrong?  Or do things just break without
> notice?
> 
Error handling is done according to RFC 3748.

> * 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?
> 

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 mnc.mcc [at] 3gppnetwork.org. 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 mnc.mcc [at] 3gppnetwork.org. 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."



> Sections 3 and 4 - These sections seem to belong with Appendix A,
> 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.

> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>