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

[Bernard Aboba (aboba]

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.