[EMAIL PROTECTED] wrote:
> http://perso.rd.francetelecom.fr/bersani/EAP_PSK/EAP-PSK.htm
> We intend to publish the first EAP-PSK implementation
> in the next weeks.
PLEASE fix the protocol. PLEASE PLEASE fix the protocol.
------
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_IDRES | Length | Actual Identity Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Identity :
: . :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
The identity does not include any terminating null characters.
Because the length of the attribute must be a multiple of 4 bytes,
the sender pads the identity with zero bytes when necessary.
----
The "actual identity length" field is NOT needed. DELETE IT.
Having two lengths is a recipe for disaster. In fact, inventing a new
attribute format is a waste of time.
See the EAP-TTLS draft for examples of a better attribute design.
It uses one length, padded fields, and there are NO problems.
The extra bytes sent in the packets by using EAP-TTLS attributes
instead of your attribute design are *irrelevant*. The code savings,
development time, maintenance, decreased bugs, and decreased security
flaws caused by re-using existing code will be HUGE.
e.g. You can steal the existing code in rlm_eap_ttls/ttls.c to
create/parse the attributes. You can define EAP-PSK-FOO attributes in
the dictionary, to re-use the existing VALUE_PAIR data structures.
The savings will be *significant*.
If you want to convince people to use your system, re-using existing
code & design is excellent practice.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
