1. Identities and Network Access Identifier in M2M Page 1 © 2010 3GPP2 3GPP2 and its Organizational Partners claim copyright in this document and individual Organizational Partners may copyright and issue documents or standards publications in individual Organizational Partner's name based on this document. Requests for reproduction of this document should be directed to the 3GPP2 Secretariat at secretariat@3gpp2.org. Requests to reproduce individual Organizational Partner's documents should be directed to that Organizational Partner. See www.3gpp2.org for more information. This document has been prepared by Bridgewater Systems to assist the development of specifications by 3GPP2. It is proposed to the specification formulating group as a basis for discussion and is not to be construed as a binding proposal on the contributor. Huawei Technologies specifically reserves the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property of Bridgewater Systems. Bridgewater Systems is also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing 3GPP2’s specifications which incorporates this contribution. Notice: M2M-20101207-004 Source:Bridgewater Systems Contact:Avi Lior avi@bridgewatersystems.com avi@bridgewatersystems.com December 6, 2010

2. Identities Identify an entity in a domain – Identity’s uniqueness can be global, in which case, for example the identities are assigned by a central body. E.g., MAC address – Identity’s uniqueness can be non-global that is, relative to a specific domain User’s login name is unique within the domain of the service provider. We can make such identities globally unique by associating globally unique information with the identity. – Eg., loginname + service provider’s globally unique identitfier

3. Authentication We authenticate because we want to ensure we provide service to known entities for various reasons. We have two parties: – Authenticator: the entity that wants to know whether something is authentic – Authoritative party: the entity trusted by the Authenticator that performs the authentication (Authentication Server) To authenticate an entity the Authoritative party typically uses the entity’s identity to find a shared secret that it and the entity being authenticated knows. – Secret: something that the authenticating party knows, or trusted third party knows. – PKI based authentication is different. To authenticate an entity, the Authenticator needs to know the Authoritative party directly or indirectly. – The Authenticator does not need to know the identity of the entity.

4. Login example Entity wants service and presents the Authenticator with an identity (login name) and authoritative party (home network) – Authenticator contacts the Authoritative party passing it the login name – The authoritative domain uses the login name to authenticate the entity. Using some authentication procedure. Two requirements: – The identity must only be unique within the context of the Authoritative party. – Authenticator must be able to locate the Authoritative party.

5. Identity Privacy - Identity Hiding For privacy reasons, the identity can be hidden from the Authenticating party. All the Authenticating party needs to know is the authoritative party or a route to it. The Authoritative party will use some mechanism to identify the entity to be authenticated. – Obtain the identity via a secured communication channel with the entity being authenticated – Use a pseudo-identity that can be used to determine the true identity.

6. Authentication with Identity Hiding Authenticator want to authenticate a device which presents to it just the Authoritative realm. The Authenticator contacts the Authoritative realm. The Authoritative realm communicates with the device getting its identity (in private) The Authoritative party signals the Authenticator whether or not the authentication succeeded.

7. Network Access Identifier NAI is designed by the IETF to accommodate the use cases described earlier as the syntax of user identifier used when roaming (RFC 4282) – Optionally carry only user identifier – Optionally carry only an authoritative domain – the home operator – Optionally specify routing – routing decoration – Other decoration (not in RFCs but commonly used) Used by many of the IETF protocols and other SDOs In AAA it is used to help the AAA client and proxy route AAA messages to the home network.

8. NAI Examples Only identifier: avi Only authoritative domain: @example.com Both identifier and authoritative domain: – avi@example.com avi@example.com Routing decoration: – hop2.com!example.com!avi@hop1.com hop2.com!example.com!avi@hop1.com Other decoration: – example.com!{sm=1}avi@hop1.com

9. NAI Size Usage of NAI determines its ultimate size: – Size of the identity portion – Size of the realm – Size of routing realms and number of them. 4282: handle at least 72 octets recommended 253. – 3GPP2: 72 octets over RADIUS is the max. Depends on the protocol being used as well. – RADIUS max is 253 octets – Diameter max is 2^24 – 9 octets

10. Identity portion of the NAI When we send an identity in the NAI then it should only be used by the home realm. From RFC 4282: “Interpretation of the username part of the NAI depends on the realm in question. Therefore, the "username" part SHOULD be treated as opaque data when processed by nodes that are not a part of the authoritative domain (in the sense of Section 4) for that realm.” In other RFCs (5216 2.1.4) where user privacy can be accommodated it is recommended that the NAI used to route the AAA message does not include the username/identity at all – so called Privacy Network Access Identifier.

11. M2M and NAI Whether NAI is used or not is not the issue: – NAI will be used to convey information over the protocols. The question is what goes in the NAI. – That is driven by different requirements and use cases. – The NAI is part of the tool kit we provide.

12. M2M Identities What are we identifying: – M2M Device? – M2M Service subscription? – M2M cdma2000 modem? – M2M cdma2000 Subscription? – PAN modem? – PAN subscription? Recomendation; – 3GPP2 worry about M2M cdma2000 subscription and M2M 3GPP2 modem identifier – These identifiers could also be used by M2M service layer if desired.

13. Which NAI format to use? Determined by the procedure being performed: – Are we doing device/modem authentication? – Are we doing subscription authentication? Are we enabling identity privacy? What are the roaming requirements? What other NAI decoration is needed?

14. Bottom line… Determine what the identifier is identifying and how big should it be. – There are size constraints In the case where the identifier is sent then the maximum size over RADIUS is 253 octets which includes everything you put in the NAI. Keep it as small as you can. Is it globally unique or is it unique in the context of a home realm – If it is globally unique which registry is controlling it. Do we need to convey it outside the home realm? – Recall the identity is really only required by the home realm. – If not, we better understand why? – Privacy concerns of revealing the true identity. Do we need to know in the RAN or PDSN etc whether the entity is an M2M Device, Device type or group(s) it belongs to during the authentication process. Or can we have that information conveyed after the authentication What is needed for successful M2M roaming model. – Note: the actually identity may be the least important aspect.