EAP-TTLS peer: Fix parsing auth= and autheap= phase2 params
This patch fixes an issue with an invalid phase2 parameter value
auth=MSCHAPv2 getting interpreted as auth=MSCHAP (v1) which could
degrade security (though, only within a protected TLS tunnel). Now when
invalid or unsupported auth= phase2 parameter combinations are
specified, EAP-TTLS initialization throws an error instead of silently
doing something.
More then one auth= phase2 type cannot be specified and also both auth= and
autheap= options cannot be specified.
Parsing phase2 type is case sensitive (as in other EAP parts), so phase2
parameter auth=MSCHAPv2 is invalid. Only auth=MSCHAPV2 is correct.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
[Use cstr_token() to get rid of unnecessary allocation; cleanup] Signed-off-by: Jouni Malinen <j@w1.fi>