[PATCHv10] Use radius supplied Passphrase for WPA-PSK

michael-dev michael-dev at fami-braun.de
Thu Dec 22 04:24:49 EST 2011


Hi,

thanks for committing.

The intention of Service-Type was to find out if the username/password 
is supplied by the user and should therefore be checked.
For hostapd, this can be done by using a different freeradius/eap 
virtual_server configuration that indicates the eap authentication
to the database bankend, but as some new switches from hp support mac 
based authentication with eap, I hoped to find something else.
Currently, I work around this by comparing username and calling station 
id which works quite nicely but limits the usernames the users may 
choose a bit.

As far as I read the RFC, I don't think the Service-Type could cause 
any trouble due to sticking to the standards on the server side.
Maybe it would be better to make the Service-Type value runtime 
configurable and permit giving different values for EAP/non-EAP? Or even 
allow the use of different radius configuration (NAS Identifier, etc)?
If somebody knows a better radius attribute to indicate the kind of 
authentication requested (username/password check versus 
Calling-Station-Id check), I would be glad to hear.

Regards,
  M. Braun



On Sun, 11 Dec 2011 13:13:18 +0200, Jouni Malinen wrote:
> On Thu, Dec 08, 2011 at 11:04:32AM +0100, michael-dev at fami-braun.de 
> wrote:
>> please find attached a new revision of the patch. I made the radius 
>> function to read the tunneled password
>> respect the tag attribute and return the tunneled password with the 
>> lowest tag just as get_vlanid does.
>
> Thanks. I applied the Tunnel-Password/PSK parts, but left 
> Service-Type
> addition out for now (see below for the part that did not get
> committed). Could you please clarify the need for this? It looks a 
> bit
> odd to use different service types for EAP and MAC ACL since both of
> these are for the same purpose of getting connectivity to the 
> network.
> Is Service-Type = Outgoing really used in IEEE 802.1X/IEEE 802.11 use
> cases? Or could it cause problems if the RADIUS server validates this
> somehow?
>
> It should be possible to distinguish the different RADIUS use cases
> already by checking whether EAP-Message attribute is included.
>
>
> diff --git a/src/ap/ieee802_11_auth.c b/src/ap/ieee802_11_auth.c
> index f3f313d..0c03bbb 100644
> --- a/src/ap/ieee802_11_auth.c
> +++ b/src/ap/ieee802_11_auth.c
> @@ -192,6 +192,12 @@ static int hostapd_radius_acl_query(struct
> hostapd_data *hapd, const u8 *addr,
>  		goto fail;
>  	}
>
> +	if (!radius_msg_add_attr_int32(msg, RADIUS_ATTR_SERVICE_TYPE,
> +				       RADIUS_SERVICE_TYPE_OUTBOUND)) {
> +		wpa_printf(MSG_DEBUG, "Could not add Service-Type");
> +		goto fail;
> +	}
> +
>  	os_snprintf(buf, sizeof(buf), "CONNECT 11Mbps 802.11b");
>  	if (!radius_msg_add_attr(msg, RADIUS_ATTR_CONNECT_INFO,
>  				 (u8 *) buf, os_strlen(buf))) {
> diff --git a/src/ap/ieee802_1x.c b/src/ap/ieee802_1x.c
> index 153b271..0f3b716 100644
> --- a/src/ap/ieee802_1x.c
> +++ b/src/ap/ieee802_1x.c
> @@ -509,6 +509,12 @@ static void ieee802_1x_encapsulate_radius(struct
> hostapd_data *hapd,
>  		goto fail;
>  	}
>
> +	if (!radius_msg_add_attr_int32(msg, RADIUS_ATTR_SERVICE_TYPE,
> +				       RADIUS_SERVICE_TYPE_FRAMED)) {
> +		printf("Could not add Service-Type\n");
> +		goto fail;
> +	}
> +
>  	if (sta->flags & WLAN_STA_PREAUTH) {
>  		os_strlcpy(buf, "IEEE 802.11i Pre-Authentication",
>  			   sizeof(buf));
> diff --git a/src/radius/radius.c b/src/radius/radius.c
> index 3ead847..651b76f 100644
> --- a/src/radius/radius.c
> +++ b/src/radius/radius.c
> @@ -173,6 +173,7 @@ static struct radius_attr_type radius_attrs[] =
>  	{ RADIUS_ATTR_USER_PASSWORD, "User-Password", RADIUS_ATTR_UNDIST },
>  	{ RADIUS_ATTR_NAS_IP_ADDRESS, "NAS-IP-Address", RADIUS_ATTR_IP },
>  	{ RADIUS_ATTR_NAS_PORT, "NAS-Port", RADIUS_ATTR_INT32 },
> +	{ RADIUS_ATTR_SERVICE_TYPE, "Service-Type", RADIUS_ATTR_INT32 },
>  	{ RADIUS_ATTR_FRAMED_MTU, "Framed-MTU", RADIUS_ATTR_INT32 },
>  	{ RADIUS_ATTR_REPLY_MESSAGE, "Reply-Message", RADIUS_ATTR_TEXT },
>  	{ RADIUS_ATTR_STATE, "State", RADIUS_ATTR_UNDIST },
> diff --git a/src/radius/radius.h b/src/radius/radius.h
> index e69a047..ec688ea 100644
> --- a/src/radius/radius.h
> +++ b/src/radius/radius.h
> @@ -52,6 +52,7 @@ enum { RADIUS_ATTR_USER_NAME = 1,
>         RADIUS_ATTR_USER_PASSWORD = 2,
>         RADIUS_ATTR_NAS_IP_ADDRESS = 4,
>         RADIUS_ATTR_NAS_PORT = 5,
> +       RADIUS_ATTR_SERVICE_TYPE = 6,
>         RADIUS_ATTR_FRAMED_MTU = 12,
>         RADIUS_ATTR_REPLY_MESSAGE = 18,
>         RADIUS_ATTR_STATE = 24,
> @@ -146,6 +147,19 @@ enum { RADIUS_ATTR_USER_NAME = 1,
>  #define RADIUS_TUNNEL_MEDIUM_TYPE_IPV6 2
>  #define RADIUS_TUNNEL_MEDIUM_TYPE_802 6
>
> +/* Service-Type */
> +#define RADIUS_SERVICE_TYPE_LOGIN 1
> +#define RADIUS_SERVICE_TYPE_FRAMED 2
> +#define RADIUS_SERVICE_TYPE_CALLBACK_LOGIN 3
> +#define RADIUS_SERVICE_TYPE_CALLBACK_FRAMED 4
> +#define RADIUS_SERVICE_TYPE_OUTBOUND 5
> +#define RADIUS_SERVICE_TYPE_ADMINISTRATIVE 6
> +#define RADIUS_SERVICE_TYPE_NAS_PROMPT 7
> +#define RADIUS_SERVICE_TYPE_AUTHENTICATE_ONLY 8
> +#define RADIUS_SERVICE_TYPE_CALLBACK_NAS_PROMPT 9
> +#define RADIUS_SERVICE_TYPE_CALL_CHECK 10
> +#define RADIUS_SERVICE_TYPE_CALLBACK ADMINISTRATIVE 11
> +
>
>  struct radius_attr_vendor {
>  	u8 vendor_type;



More information about the HostAP mailing list