diff mbox

[4/4] EAP-SIM/EAP-AKA peer: Support realms according to 3GPP TS 23.003

Message ID 8229f081493e769d577f7fbaeea0352cd89a72e4.1326658542.git.gmbnomis@gmail.com
State Accepted
Commit 2d7d0ab307443e196d1517cccbc058229815419c
Headers show

Commit Message

Simon Baatz Jan. 15, 2012, 8:32 p.m. UTC 
If the identity is derived from the SIM, use a realm according
to 3GPP TS 23.003.

Signed-hostap: Simon Baatz <gmbnomis@gmail.com>
---
 src/eap_peer/eap.c |   47 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 46 insertions(+), 1 deletions(-)

Comments

Jouni Malinen Jan. 22, 2012, 7:57 p.m. UTC | #1 
On Sun, Jan 15, 2012 at 09:32:48PM +0100, Simon Baatz wrote:
> If the identity is derived from the SIM, use a realm according
> to 3GPP TS 23.003.

Thanks! Applied.
Simon Baatz Jan. 23, 2012, 7:48 p.m. UTC | #2 
Hi Jouni,

Am 22.01.2012 20:57, schrieb Jouni Malinen:
> On Sun, Jan 15, 2012 at 09:32:48PM +0100, Simon Baatz wrote:
>> If the identity is derived from the SIM, use a realm according
>> to 3GPP TS 23.003.
> Thanks! Applied.
>

Great, thanks! You did not apply patches 1/4 and 2/4 (use the realm of
the permanent identity for the pseudonym as well). This is needed to
make pseudonyms work in environments that need a realm. Is there a
specific reason for not applying the patches, or is this just an oversight?

- Simon
Jouni Malinen Jan. 23, 2012, 8:23 p.m. UTC | #3 
On Mon, Jan 23, 2012 at 08:48:32PM +0100, Simon Baatz wrote:
> Great, thanks! You did not apply patches 1/4 and 2/4 (use the realm of
> the permanent identity for the pseudonym as well). This is needed to
> make pseudonyms work in environments that need a realm. Is there a
> specific reason for not applying the patches, or is this just an oversight?

They are still in the queue since I did not have time to test them yet.
You can see the status of pending patches at
http://patchwork.ozlabs.org/project/hostap/list/

Talking of those patches, I would assume something similar would be
needed for fast reauthentication case, too. Or was that already covered
in those patches?
Simon Baatz Jan. 23, 2012, 9:25 p.m. UTC | #4 
Am 23.01.2012 21:23, schrieb Jouni Malinen:
> On Mon, Jan 23, 2012 at 08:48:32PM +0100, Simon Baatz wrote:
>> Great, thanks! You did not apply patches 1/4 and 2/4 (use the realm of
>> the permanent identity for the pseudonym as well). This is needed to
>> make pseudonyms work in environments that need a realm. Is there a
>> specific reason for not applying the patches, or is this just an oversight?
> They are still in the queue since I did not have time to test them yet.
> You can see the status of pending patches at
> http://patchwork.ozlabs.org/project/hostap/list/

I see. Sorry to be so impatient...

> Talking of those patches, I would assume something similar would be
> needed for fast reauthentication case, too. Or was that already covered
> in those patches?
>

For the fast reauthentication IDs the server may choose a different
realm. This makes sense if one has multiple EAP servers. If the realm
used for fast reauth points to a specific server, the fast reauth
context may be only local to this specific server. There is no need to
synchronize the state across servers or to store it persistently.
That's why AT_NEXT_REAUTH_ID must already contain both a username and a
realm if the realm is needed. (see section 5.3 of RFC 4186/4187)

- Simon
Jouni Malinen Jan. 28, 2012, 5:44 p.m. UTC | #5 
On Mon, Jan 23, 2012 at 10:25:10PM +0100, Simon Baatz wrote:
> For the fast reauthentication IDs the server may choose a different
> realm. This makes sense if one has multiple EAP servers. If the realm
> used for fast reauth points to a specific server, the fast reauth
> context may be only local to this specific server. There is no need to
> synchronize the state across servers or to store it persistently.
> That's why AT_NEXT_REAUTH_ID must already contain both a username and a
> realm if the realm is needed. (see section 5.3 of RFC 4186/4187)

OK. Thanks for the pseudonym realm update - both patch 1 and 2 are now
applied.
diff mbox

Patch

diff --git a/src/eap_peer/eap.c b/src/eap_peer/eap.c
index 91fa4a9..02070d7 100644
--- a/src/eap_peer/eap.c
+++ b/src/eap_peer/eap.c
@@ -878,6 +878,51 @@  static void eap_sm_processIdentity(struct eap_sm *sm, const struct wpabuf *req)
 
 
 #ifdef PCSC_FUNCS
+static int eap_sm_append_3gpp_realm(struct eap_sm *sm,
+				    struct eap_peer_config *conf)
+{
+	char *realm_3gpp = "@wlan.mnc000.mcc000.3gppnetwork.org";
+	u8 *full_id = NULL;
+	size_t full_id_len = 0;
+	int mnc_len;
+
+	full_id = os_malloc(conf->identity_len + strlen(realm_3gpp));
+	if (full_id == NULL) {
+		wpa_printf(MSG_WARNING, "Failed to allocate buffer for "
+			   "3GPP realm");
+		return -1;
+	}
+	os_memcpy(full_id, conf->identity, conf->identity_len);
+	os_memcpy(full_id + conf->identity_len, 
+		  realm_3gpp, strlen(realm_3gpp));
+	full_id_len = conf->identity_len + strlen(realm_3gpp);
+
+	full_id[conf->identity_len + 16] = full_id[1];
+	full_id[conf->identity_len + 17] = full_id[2];
+	full_id[conf->identity_len + 18] = full_id[3];
+
+	mnc_len = scard_get_mnc_len(sm->scard_ctx);
+	if (mnc_len < 0) {
+		wpa_printf(MSG_WARNING, "Failed to get MNC length from (U)SIM"
+			   " assuming 3");
+		mnc_len = 3;
+	}
+	if (mnc_len == 2) {
+	        full_id[conf->identity_len + 10] = full_id[4];
+        	full_id[conf->identity_len + 11] = full_id[5];
+	} else if (mnc_len == 3) {
+	        full_id[conf->identity_len +  9] = full_id[4];
+	        full_id[conf->identity_len + 10] = full_id[5];
+	        full_id[conf->identity_len + 11] = full_id[6];
+	} 
+
+	os_free(conf->identity);
+	conf->identity = full_id;
+	conf->identity_len = full_id_len;
+
+	return 0;
+}
+
 static int eap_sm_imsi_identity(struct eap_sm *sm,
 				struct eap_peer_config *conf)
 {
@@ -916,7 +961,7 @@  static int eap_sm_imsi_identity(struct eap_sm *sm,
 	os_memcpy(conf->identity + 1, imsi, imsi_len);
 	conf->identity_len = 1 + imsi_len;
 
-	return 0;
+        return eap_sm_append_3gpp_realm(sm, conf);
 }
 #endif /* PCSC_FUNCS */