1. Service Access Contexts
September 2005
doc.: IEEE /0898r1
September 2005
Service Access Contexts
Date:
Authors:
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Mike Moreton, STMicroelectronics
Mike Moreton, STMicroelectronics

2. September 2005
doc.: IEEE /0898r1
September 2005
Abstract
This presentation discusses the impact of requirement R1A1 (simultaneous authentication with multiple SSPNs) and suggests a TGu architecture that might support this requirement.
Mike Moreton, STMicroelectronics
Mike Moreton, STMicroelectronics

3. 11u Terminology – a Recap DN TOE TOE SSPN 802.11 AN STA September 2005
User plane data
exchange
Authentication AN
Key and authorisation
policy download
STA
Mike Moreton, STMicroelectronics

4. September 2005
Requirement R1A1
“A STA shall be able to authenticate with different SSPNs simultaneously, in order to gain simultaneous access to multiple Destination Networks.”
One handset can simultaneously access multiple DNs
Access to each DN may be authorised by a different SSPN
Authorisation information is provided by the SSPN to configure and control the access
Mike Moreton, STMicroelectronics

5. What’s a DN? Each DN may have its own address space
September 2005
What’s a DN?
Each DN may have its own address space
Each DN may contain one or more TOEs
But what is it?
Is it a L3 network?
Is it a L2 VLAN?
Is it multiple L2 and L3 networks?
We don’t need to answer this – a DN is whatever the SSPN authentication gives access to
Zero or more gateways to remote services
Zero or more local services
Local Internet Access (or not)
The AP must be able to identify for which DN the data is destined
Beyond that is out of our scope
Mike Moreton, STMicroelectronics

6. September 2005
Why R1A1?
The model is of a single device that can simultaneously access services from more than one service provider
Football results from my home service provider
Travel and Weather from a global service
Supports many operators’ desire to move to a more service focused operation
Mike Moreton, STMicroelectronics

7. Interpretation of R1A1 What should we call this “access” to a DN?
September 2005
Interpretation of R1A1
What should we call this “access” to a DN?
There seem to be a number of characteristics associated with it, so having a name will help the description
New Definition - Service Access Context (SAC)
An SAC is the logical session that provides segmented, protected access to a single Destination Network. Creation of an SAC is based on an authentication with an SSPN.
SAC is crucial to u
Much of our work will consist of specifying the creation, destruction, and operation of SACs
Mike Moreton, STMicroelectronics

8. Security Associations
September 2005
Security Associations
Key requirement in security analysis is to determine bindings
Who knows what and in what context
In what context is security ensured
And by corollary, what security is removed when you change a context
802.11i associates an authentication and a pairwise key and both with an association
We associate an SAC with an authentication
And the only authentication mechanism we have is an i authentication, unless we want to invent a new authentication mechanism
So it’s easiest if an SAC is associated with an association
Mike Moreton, STMicroelectronics

9. The Downside of SAC/Association Binding
September 2005
The Downside of SAC/Association Binding
Binding an SAC and an Association in a 1 to 1 relationship will make may things easier architecturally
But…
It does mean that a STA with multiple active SACs will have multiple active associations
It will be difficult to handover quickly
If someone can come up with an architecture that doesn’t link SAC and association, that will be great
Mike Moreton, STMicroelectronics

10. September 2005
A Fork in the Road
Binding a SAC with an Association should be achievable
But may limit handover performance
Having multiple SACs per Association provides better handover performance
But we’ve no idea how to make it work
Do we go for the obvious path, or the one with the “Here Be Dragons” sign?
We assume that we’ll take the obvious path for now
But if anyone is brave enough to slay the dragons we’ll be very impressed
Mike Moreton, STMicroelectronics

11. Assumptions From Here On
September 2005
Assumptions From Here On
The rest of this submission assumes a 1 to 1 mapping between SAC and Association
A practical limitation to the number of SACs that can be active at once
This isn’t assumed to be a huge problem for initial applications
Mike Moreton, STMicroelectronics

12. Multiple Association Support
September 2005
Multiple Association Support
STA needs to support multiple associations
But each association is identified at the AP by the MAC address of the STA
Don’t want each STA to need multiple MAC addresses
Need a way of allocating a temporary MAC address for each association
Note – this is very similar to the allocation of temporary identities that will be required for MAC Address Anonymity
Use the same function to do both
Mike Moreton, STMicroelectronics

13. Scope of Temporary MAC Address (TMA)
September 2005
Scope of Temporary MAC Address (TMA)
When a STA roams from AP to AP, does the TMA change?
If so, allocation is easier (no co-ordination between APs required)
But TGr fast roaming would have to use real MAC address as STA identifier – are we sure TGr never exposes this?
Mapping from TMA to real MAC address in AP may make debugging more difficult.
Alternative is to keep same TMA
In some ways simpler, but requires co-ordination
Perhaps the AS is involved?
Mike Moreton, STMicroelectronics

14. 11u Functional Architecture
September 2005
11u Functional Architecture AP
STA
Gateway AS DS
Mike Moreton, STMicroelectronics

15. Rough Step by Step Process (very draft!)
September 2005
Rough Step by Step Process (very draft!)
STA associates with AP using random MAC address
STA authenticates with AS (standard )
AS configures gateway (including some Authorisation Info)
AS provides PMK to AP, plus:
Address of gateway or gateways
Some Authorisation Information
TMA
AS provides Gateway with:
Mike Moreton, STMicroelectronics