|
Hi Santosh,
Thank you for doing this, the effort is greatly appreciated.
Unfortunately, this is not the right direction, in my opinion. It continues to perpetuate the
erroneous binding of what type of address a DHCP server will serve up with how you authenticate.
It is incredibly complicated and that complication serves no apparent purpose, to the contrary,
it actually seems to make things worse.
As an example of this complexity, I will point out that it is impossible to indicate support for
both public key and shared key authentication in a single FILS Information field. This is not
a fair criticism of your good work here because that complexity was with this field already,
but as a proposal on how to move forward we have to consider the proposal completely.
If you specify shared key then there's a sequence of address type/shared key amalgamations.
If you specify public key then you refer to the contents of a field that doesn't exist as being
found in a separate IE. To further complicate matters, what is the syntax of setting the
FILS Security Type to indicate shared key (with our without PFS) and then to not set the
Subnet ID Token Present bit? It does not seem to be possible to indicate support for
shared key authentication without also including a subnet ID yet you can say that ID is
not present.
What does it mean to indicate shared key authentication and have the number of domains
be zero? I guess that would be how you indicate support for public key authentication and
PMKSA caching only. Except there's already a way to indicate that. So this is multiple ways
of saying the same thing and that is a recipe for interop fail.
Also, it does not seem useful to specify a tuple of hashed domain name, the IP address type
you will be able to get from that domain, and an opaque token whose format is outside the
scope of our standard. That is complication for no good reason.
If we want to be able to indicate FILS capabilities in this field it should be done so in a
simple and extensible manner. We should not bind the type of IP address one gets to how
you authenticate. If there are multiple things one must be able to say in an indication, then
that should not conflict with anything else in the indication element.
Let's get together tomorrow and work on it together.
regards,
Dan.
_______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
SELF SERVICE OPTION: Point your Browser to -
http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAI and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button.
Further information can be found at:
http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________
_______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this
CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
SELF SERVICE OPTION:
Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAI and
then amend your subscription on the form provided. If you require removal from the reflector
press the LEAVE button.
Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________
|