1. EAP over HRPD Comments Qualcomm, Inc. Vidya Narayanan, Dondeti, Lakshminath, Jun Wang, Pete Barany Notice: QUALCOMM Incorporated grants a free, irrevocable license to 3GPP2 and its Organization Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner’s name any Organizational Partner’s standards publication even though it may include portions of the contribution; and at the Organization Partner’s sole discretion to permit others to reproduce in whole or in part such contributions or the resulting Organizational Partner’s standards publication. QUALCOMM Incorporated is also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution. This document has been prepared by QUALCOMM Incorporated to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on QUALCOMM Incorporated. QUALCOMM Incorporated 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 QUALCOMM Incorporated other than provided in the copyright statement above.

2. Background BW, Nokia, Starent, Samsung submitted a contribution (X31-20060327-010) to comment on QUALCOMM contribution regarding EAP over HRPD proposal The group had a briefly discussed in the meeting Although we discussed and answered some of the questions, the group agreed to continue the discussions via email exchanges due to time limitation This presentation addresses the all issues that raised by X31-20060327-010.

3. Comment #1 This fixed-network-originated model is lacking the 4th element: Enforcement Point (or, NAS port). Splitting the NAS into NAS Authenticator (e.g., on PDSN) and multiple NAS ports (e.g., ANs) is needed for efficient AAA in the face of mobility.  Authenticator can be the Enforcement point.  RFC3748 already allows the model where the authenticator comprises of multiple ports or a virtual authenticator that encompasses multiple ports. Hence, inherently, this is supported in any protocol that does EAP.  In addition, we proposed session/context transfer between authenticators and there is no need to access HAAA when the handoff occurs between two authenticators.

4. Comment #2 Simply assigning a protocol ID in the lower layer is not sufficient to design an EAP transport, especially for mobile and wireless systems. Things like orderly delivery, state and session management, channel binding, key scoping, replay and DoS prevention require additional bits be carried either as other payloads along EAP or otherwise EAP lower layer requirements are specified in RFC3748. Here is a list of reqs and non-reqs from 3748: –Unreliable transport is a non-req (if xport is unreliable, it must be resilient to Success and Failure messages being lost). –Lower layer error detection is required. –Lower layer security is a non-req. –Lower layer fragmentation and reassembly is desirable. –Non-duplicate delivery is desirable (this applies when the lower layer is reliable to begin with) –Ordering guarantee from lower layer is required. EAP over HRPD meets all of the above Channel binding, state/session management, key scoping, replay and DoS prevention, etc. quoted above in the comment are not specified EAP lower layer requirements. In addition, we have submitted GEE protocol to IETF to address allowing parallel access and service authentications etc.

5. Comment #3 This approach forces the NAS to be on the AN. If 3GPP2 needs to support NAS on the PDSN, then additional protocol work is needed. The complexity of the additional protocol work (either split MAC, or EAP forwarding/proxying) is open for discussion. The proposal is to have the authenticator in the RRM for access authentication. Even if the authenticator is in the PDSN for service authentication, that only means that the RRM is simply relaying the EAP messages between the PDSN and the AT and it is less complex than running EAP over PANA over UDP over IP.

6. Comment #4 Unless we know for sure that the lower layers will always provide reliable delivery, omission of an (EAP Success/Failure) acknowledgement from the AT is a bad design (not to be copied from other EAP lower layers). It can lead to loss of state synchronization, deadlock, layer violations, or added inter-layer communication. The RLP sequence number provides reliable unicast delivery.

7. Comment #5 Due to lack of cryptographic binding between the EAP-AKA and EAP-MD5, this design is open to MitM attacks. EAP-AKA supports mutual authentication. EAP-MD5 runs inside a mutually authenticated secure channel, and so no cryptographic binding is required as a MiTM attack is not possible on a mutually authenticated channel. In addition, EAP-MD5 is just an example we are using in the contribution.