Internet DRAFT - draft-mccann-session-policy-framework-using-eap
draft-mccann-session-policy-framework-using-eap
EMU Working Group S. McCann
Internet Draft Research in Motion
Intended status: Standards Track M. Montemurro
Expires: July 8, 2013 Research in Motion
January 8, 2013
Session Policy Framework using EAP
draft-mccann-session-policy-framework-using-eap-07.txt
Abstract
This document specifies a framework for implementing a session policy
channel using EAP. It defines a standard mechanism by which a mobile
device can conduct a session policy exchange with a policy network
component, using EAP as a lower layer protocol, to obtain session
policies. EAP Re-authentication Protocol is suggested as a mechanism
to allow asynchronous use of SIP at upper layers.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 8, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
McCann Expires July 8, 2013 [Page 1]
Internet-Draft Session Policy Framework using EAP January 2013
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction ..................................................... 3
2. Terminology ...................................................... 3
3. Session Policy ................................................... 4
3.1. SIP background ............................................... 4
3.2. 3GPP IMS ..................................................... 4
3.3. Management of Asynchronous Session Events .................... 6
4. Session policy channel ........................................... 6
4.1. Session Policy Documents ..................................... 7
4.1.1. Network Triggered Policy Change .......................... 8
5. Architecture Considerations ...................................... 8
5.1. Session Policy Exchange (SPE) ................................ 8
5.1.1. Session Policy Channel Initialization .................... 9
5.1.2. Session Establishment (Mobile Device Triggered) ......... 10
5.1.3. Session Establishment (Network Triggered) ............... 11
6. Encapsulation of SPEs ........................................... 12
6.1. Encapsulation within an TLV ................................. 12
6.2. Encapsulation within an AVP ................................. 13
6.2.1. Session Policy Exchange AVP ............................. 13
6.2.2. Session Policy Change Event AVP ......................... 14
7. Use with SIP .................................................... 15
8. Security Considerations ......................................... 15
9. IANA Considerations ............................................. 15
McCann Expires July 8, 2013 [Page 2]
Internet-Draft Session Policy Framework using EAP January 2013
9.1. Registration of EAP Session Policy TLV ...................... 15
9.2. Registration of Diameter Session Policy AVP ................. 16
10. References ..................................................... 16
10.1. Normative References ....................................... 16
10.2. Informative References ..................................... 16
11. Specific Transport Mechanism ................................... 16
12. Acknowledgments ................................................ 17
13. Authors' Addresses ............................................. 17
1. Introduction
The Session Initiation Protocol (SIP) [RFC 3261] is an application-
layer control (signaling) protocol for creating, modifying and
terminating sessions with one or more participants. These sessions
can include VoIP (Voice over IP) telephone calls, and multimedia
conferences. Service providers may have policies that apply to the
media types negotiated for SIP sessions and hence it is necessary for
proxy servers to be able to influence the Session Description
Protocol negotiation during SIP session establishment and
modification.
This document specifies an alternative policy channel mechanism,
enabling a user agent (i.e. a mobile device) to send session policy
requests to a policy network component (e.g. a policy server) using a
lower layer protocol (e.g. EAP and PPP), to obtain session policies,
primarily for bandwidth constrained networks.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119
[RFC2119].
A mixture of both EAP and SIP terminology is used within this
document, with the following equivalence:
EAP client = SIP user agent (UA) = Mobile Device
EAP peer = Home Network Server = AAAh
Authenticator = Intermediate Component (IC) = Gateway
In addition, this document uses the following terms:
ERP - EAP re-authentication Protocol
McCann Expires July 8, 2013 [Page 3]
Internet-Draft Session Policy Framework using EAP January 2013
IMS - IP Multimedia Subsystem
PCC - Policy Control and Charging
PNC - Policy Network Component
PNCh - Home PNC
PNCv - Visited PNC
SDP - Session Description Protocol
SIP - Session Initiation Protocol
SPE - Session Policy Exchange (i.e. session policy request and
response)
3. Session Policy
3.1. SIP background
Using SIP for the policy channel provides a good general purpose
solution for the internet being independent of the underlying policy
and network architecture and ensures that all SIP user agents (mobile
devices) can interact with any PNC. However, for limited bandwidth
access networks, such as cellular systems, the SIP Events framework
[RFC 3265] is an inefficient realization of the policy channel. With
limited bandwidth access networks the large SIP messages take a
significant amount of time to be transported between the mobile
device and a PNC.
3.2. 3GPP IMS
3GPP has defined IMS as a next generation network architecture for
establishing IP multimedia sessions including services such as
multimedia telephony. Although originally developed for cellular
networks, other technologies such as fixed line DSL networks and
DOCSIS cable networks together with wireless technologies such as
WLAN and WIMAX can be used to access IMS networks and work is
currently in progress to use IMS for SIP based enterprise access and
interconnect.
3GPP has defined an architecture for Policy Control and Charging
(PCC), realized by PNCs, that performs the necessary Authorization
and Accounting functions for mobile device access to IMS bearer
resources. Typical PNCs are policy servers, entities with "Policy
Control and Charging Rules Function" or "Policy Control and
Enforcement Functions", which based on inputs from various sources,
determines which mobile devices are allowed bearer access based on
the attributes and characteristics of the session (such as the number
of streams, the media types, and the codecs).
Within these architectures, IMS PNCs are usually co-located with the
AAA, so network paths are already established.
McCann Expires July 8, 2013 [Page 4]
Internet-Draft Session Policy Framework using EAP January 2013
McCann Expires July 8, 2013 [Page 5]
Internet-Draft Session Policy Framework using EAP January 2013
As the separate PNCs within the PCC communicate using the Diameter or
RADIUS protocol it is quite appropriate that a mature authentication
protocol be considered for session policy establishment, operating
within a Diameter and RADIUS AAA server regime.
EAP is a good candidate because it allows a mobile device to
communicate with AAA infrastructure. Its advantages are:
1. IMS PNCs use Diameter or RADIUS and EAP already operates over
these networks without requiring an upgrade.
2. EAP is already implemented or will be implemented in many mobile
terminals since EAP is specified for use by mobile terminals for
authentication when using WLAN access.
3. EAP is access independent and compatible for use with all the
access networks and policy control architectures of the current IMS
stakeholders.
4. EAP is a lightweight protocol that is efficient for transport over
bandwidth constrained access networks with minimal round trip delay
and power consumption.
3.3. Management of Asynchronous Session Events
Although EAP does show some advantages, it is primarily designed to
be an authentication mechanism, which establishes a security
association (SA), prior to any application session being considered.
In this respect EAP exchanges are expected to occur once a wireless
connection has been made, as opposed to every time a SIP session
wishes to commence.
However, using the EAP Re-authentication Protocol [RFC5296], it is
possible to re-establish an EAP method independent tunnel, with a
similar security association to that of the initial EAP exchange. It
supports EAP re-authentication for a mobile device (i.e. the EAP
peer) that has valid, unexpired key material from a previously
performed EAP authentication
In this manner, ERP can be utilized every time the mobile device
wishes to initialize a SIP session.
4. Session policy channel
An EAP based session policy channel is an alternative mechanism for
implementing the policy channel defined in [I-D.ietf-sip-session-
policy-framework] that builds upon the capabilities that exist in IMS
McCann Expires July 8, 2013 [Page 6]
Internet-Draft Session Policy Framework using EAP January 2013
networks while being more suited for use by SIP mobile devices in
these bandwidth constrained networks.
domain 1
+-----------+
.------| proxy |----...
+--------+ / +-----------+
| |---' +-----------+
| | | PNC |
| mobile |============| |
| device | +-----------+
| |**** +-----------+
+--------+ * | policy |
*******|enforcement|****...
+-----------+
--- EAP Signaling
=== Session Policy Channel
*** Media
Figure 1 - Session Policy Architecture
Figure 1 illustrates a system in which SPEs are sent by encapsulating
the messages within EAP. In the process of authenticating the mobile
device, a lower layer communication path (equivalent to a session
policy channel) is created between the mobile device and the PNC.
The mobile device sends the session policy request to a PNC using a
generic message (section 6.1. ) encapsulated within an EAP TLV
message [I-D.draft-cam-winget-eap-tlv]. The session policy response
sends the resulting session policy documents from the PNC back to the
mobile device.
Although only one PNC is shown in Figure 1, multiple PNCs could be
present in the system.
4.1. Session Policy Documents
Session policy documents are typically the info offer, info answer ,
policy offer and policy answer, which define policy as stated in [I-
D.ietf-sip-session-policy-framework].
These documents are carried within the SPE messages as shown in
section 6.
McCann Expires July 8, 2013 [Page 7]
Internet-Draft Session Policy Framework using EAP January 2013
The mobile device gains access to the PNC to obtain the session
policy documents based on a URI (Uniform Resource Indicator) provided
in the SPE message header.
4.1.1. Network Triggered Policy Change
For session-dependent policies, if the session policies change during
a session (because of a change in the available radio resources, for
example due to congestion or change of access network type), the PNC
sends a modified session policy document (Figure 4) to the mobile
device to inform it that the policies have changed so that the mobile
device can re-start a new SPE, which re-negotiates the session
policy.
5. Architecture Considerations
The SPEs are access network agnostic. The SPE passes through an IC
(e.g. gateway, access point, network access server) between the
mobile device and the PNC. The mobile device connects to an IC via
one or more of several different wired (e.g. DSL networks and DOCSIS)
or wireless (e.g. WLAN and WiMAX) access network technologies.
Essentially a lower layer protocol (e.g. a wired or wireless protocol
together with EAP) is used for transporting the session policy
request between the mobile device and the IC, and then another lower
layer protocol (e.g. RADIUS or Diameter together with EAP) transports
the session policy request between the IC and the PNC.
Since these architectures typically rely on Diameter or RADIUS based
PNCs, the mobile device can transmit SPEs to the PCN, regardless of
which access networks the mobile device uses to finally connect to
the network.
5.1. Session Policy Exchange (SPE)
From a single PNC, together with the appropriate AAA servers (such as
other PNCs), the SPEs can traverse many other network components and
cross domains. This potentially enables a PNC at the edge of the
network (subject to service agreements) to communicate with other
PNCs in other domains in order to supply a composite policy document
reflecting the policies from multiple domains that the SIP signaling
request traverses.
The mobile device can contact many PNCs via a single SPE with its
home PNC (PNCh). The PNCh contacts other visited PNCs (PNCv) and
returns their policy documents back to the PNCh where they are
McCann Expires July 8, 2013 [Page 8]
Internet-Draft Session Policy Framework using EAP January 2013
aggregated before returning that aggregated policy information to the
mobile device.
Thus the mobile device can potentially obtain a single policy
document that reflects the session policies of all the impacted
domains in a single SPE instead of having to contact multiple PNCs
individually.
As the mobile device transmits a session policy request to the PNC
using a tunneled EAP protocol (e.g. using EAP-FAST or EAP-TTLS), the
SPE is secure within an authenticated outer tunnel.
5.1.1. Session Policy Channel Initialization
The following message flow illustrates how a mobile device initiates
the session policy channel.
Mobile Device IC AAAv(PNCv) AAAh(PNCh)
| | | |
|(1) EAP Method Exchange (tunnel initialization) |
|<----------------->|<------------------------------------->|
| | | |
|(2) [SIP registration with PNCh] | |
|<--------------------------------------------------------->|
| | | |
Figure 2 - EAP Tunnel Initialization
Message Details:
(1) EAP Method Exchange (tunnel initialization)
An EAP exchange is performed between the mobile device and the PNC
with the authentication messages being forwarded to the home network
AAA server. It is assumed that the PNCh is co-located with the AAAh.
A suitable EAP method is used to establish a tunnel (e.g. EAP-FAST),
from which the relevant ERP keys are derived for subsequent use
[RFC5296].
(2) [SIP registration with PNCh]
Although not a part of the layer 2 exchange, it is worth showing that
SIP registration between the mobile device and the PNCh occurs at
this point. Subsequent SIP level flows are not shown.
McCann Expires July 8, 2013 [Page 9]
Internet-Draft Session Policy Framework using EAP January 2013
5.1.2. Session Establishment (Mobile Device Triggered)
The following message flow illustrates how a mobile device initiates
a session policy using a re-established EAP tunnel. This is a result
of a mobile device triggered event.
Mobile Device IC AAAv(PNCv) AAAh(PNCh)
| | | |
|(3) EAP-Initiate/Re-auth | |
|---------------------------------------------------------->|
| | | |
|(4) EAP tunnel(Policy Request) | |
|<--------------------------------------------------------->|
| | | |
| | | (5)Policy-h |---
| | | | |
| | | |<--
| | (6)AAA (Policy Request) |
| | |<------------------|
| | | |
| | (7)AAA (Policy Response) |
| | |------------------>|
| | | |
|(8) EAP tunnel(Policy Response) | |
|<----------------------------------------------------------|
| | | |
Figure 3 - Mobile Device Triggered Session Policy Request
Message Details:
(3) EAP-Initiate/Re-auth
The ERP exchange is performed between the mobile device and the home
AAA (PNCh).
(4) EAP tunnel(Policy Request)
The session policy request is transported within the EAP tunnel
(using EAP TLV - 6.1) to the PNCh.
(5) Policy-h
At the home AAA server, the home network policy is determined for
subsequent SIP sessions.
(6) AAA (Policy Request)
McCann Expires July 8, 2013 [Page 10]
Internet-Draft Session Policy Framework using EAP January 2013
The home AAA server, requests policy information from all visited
networks PNCs, through which the SIP session will traverse, utilizing
an AAA Policy Request message (typically using RADIUS or Diameter.)
(7) AAA (Policy Response)
Each visited PNC will return its network policy back to the home
network, where the session policy document is aggregated.
(8) EAP tunnel(Policy Response)
The session policy document is encapsulated within the EAP TLV,
before being returned to the mobile device.
5.1.3. Session Establishment (Network Triggered)
The following message flow illustrates how a network initiates a
session policy re-establishment. This is a result of a network
triggered event.
Mobile Device IC AAAv(PNCv) AAAh(PNCh)
| | | |
| | (9)AAA(Policy Change) |
| | |------------------>|
| | | |
(11) EAP Initiate/Re-auth-Start (10)AAA(Policy Change Event)|
|<------------------|<--------------------------------------|
| | |
|(3) EAP re-establish Tunnel(Channel Bindings) |
|<--------------------------------------------------------->|
| | | |
|(4) EAP tunnel(Policy Request) | |
|---------------------------------------------------------->|
| | | |
|(8) EAP tunnel(Policy Response) | |
|<----------------------------------------------------------|
| | | |
Figure 4 - Network Triggered Session Policy Request
Message Details:
(9) AAA (Policy Change)
McCann Expires July 8, 2013 [Page 11]
Internet-Draft Session Policy Framework using EAP January 2013
A visited PNC changes the session policy (most likely whilst the
mobile device session is on-going) and indicates to the PNCh that a
policy change has occurred.
(10) AAA (Policy Change Event)
The PNCh sends a policy change event message to the IC (most likely
within RADIUS or Diameter)
(11) EAP Initiate/Re-auth-Start
The IC requests the mobile device to execute the ERP.
The rest of the message flow continues, as described above in section
5.1.2.
6. Encapsulation of SPEs
The SPE comprises identification, routing and session policy
documents, which allows the policy information to be generated
(typically within the session policy documents themselves), as the
SPEs traverse the network.
The SPE is encapsulated within an EAP type-length-value (TLV)
structure between the mobile device and the PCNh and within a
RADIUS/Diameter AVP message for the onward network traversal between
the PCNh and PCNv(s).
6.1. Encapsulation within an TLV
[I-D.draft-cam-winget-eap-tlv] explains how type-length-value (TLV)
structures, may be used to transport the SPE from the mobile device
to a PNC within a secure tunnel.
The SPE TLV is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Policy Exchange (SPE)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags
M
McCann Expires July 8, 2013 [Page 12]
Internet-Draft Session Policy Framework using EAP January 2013
0 - Optional TLV
R
Reserved, set to zero (0)
TLV Type
<Defined by IANA>
Length
>=0
Session Policy Exchange
This is the Session Policy Exchange (SPE) as defined in section
5.1.
The following is an example of such a message from the network to the
mobile device:
EAP Code: 2 (Response)
Type: <IANA> SessionPolicy
Length: Variable
Value:
[Session Policy Request]
6.2. Encapsulation within an AVP
The attribute-value-pair (AVP) structure, may be used to transport
the 2 new required AAA messages as defined in section 5.1.2
6.2.1. Session Policy Exchange AVP
The structure to transport the SPE from the PNCh to various PNCv(s)
is defined as:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V M P r r r r r| AVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Policy Exchange (SPE)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
<Defined by IANA>
McCann Expires July 8, 2013 [Page 13]
Internet-Draft Session Policy Framework using EAP January 2013
Flags
V
0 - Not a vendor specific AVP
M
0 - Optional AVP
P
0 - End to end encryption is not required
AVP Length
>=0
Session Policy Exchange (SPE)
This is the Session Policy Exchange as defined in section 5.1
6.2.2. Session Policy Change Event AVP
The structure to transport the session change event from the PNCh to
the IC is defined as:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V M P r r r r r| AVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Policy Change Event...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
<defined by IANA>
Flags
V
0 - Not a vendor specific AVP
M
0 - Optional AVP
P
0 - End to end encryption is not required
McCann Expires July 8, 2013 [Page 14]
Internet-Draft Session Policy Framework using EAP January 2013
AVP Length
>=0
Session Policy Change Event
This is a message which indicates to the IC, that the session
policy within the network has changed. It triggers the IC to send an
EAP-Initiate to the mobile device, requesting that a further SPE be
re-started.
7. Use with SIP
The EAP mechanisms described above can be used by the mobile device
for obtaining both session-independent policies and session-specific
policies, as defined in [I-D.ietf-sip-session-policy-framework]. The
above discussion focuses on obtaining session-specific polices, but
the mechanisms can also be used by the mobile device prior to session
establishment to obtain session-independent policies.
In addition to media policies, the mechanisms defined herein can be
used to inform the mobile device to use a different IP address in the
SDP Offer or Answer, to navigate firewalls or NATs, or to route media
via a transcoder or other media relay as defined in [I-D.ietf-sip-
session-policy-framework].
8. Security Considerations
Session policies can significantly change the behavior of a mobile
device and can be used by an attacker to compromise such a device.
For example, session policies can be used to prevent a mobile device
from successfully establishing a session (e.g., by setting the
available bandwidth to zero). Such a policy can be submitted to the
mobile device during a session, which causes the mobile device to
terminate the session.
For transmissions over the air, [I-D. draft-cam-winget-eap-tlv]
assures that the SPE (encapsulated within an EAP TLV) is transmitted
within an authenticated tunnel using a suitable EAP method (e.g. EAP-
FAST or EAP-TTLS)
9. IANA Considerations
9.1. Registration of EAP Session Policy TLV
Name of Header Field: TLV Type
Short form: none
McCann Expires July 8, 2013 [Page 15]
Internet-Draft Session Policy Framework using EAP January 2013
Normative description: Section 6.1 of this document
9.2. Registration of Diameter Session Policy AVP
Name of Header Field: AVP Code
Short form: none
Normative description: Section 6.2 of this document
10. References
10.1. Normative References
[I-D.ietf-sip-session-policy-framework]
Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework
for Session Initiation Protocol (SIP) Session Policies",
draft-ietf-sip-session-policy-framework-10 (work in
progress), Feburary 2011.
[I-D.draft-cam-winget-eap-tlv]
Cam-Winget, N.,Zhou, H., McCann, S., "EAP Type-Length-Value
Container", draft-cam-winget-eap-tlv-02 (work in progress)
, January 2011
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B. et al, "Extensible Authentication Protocol
(EAP)", June 2004
[RFC5296] Narayanan, V., "EAP Extensions for EAP Re-authentication
Protocol (ERP)", August 2008
10.2. Informative References
[RFC3261] Rosenberg, J. et al, "SIP: Session Initiation Protocol",
June 2002
[RFC3265] Roach, A.B., "Session Initiation Protocol (SIP)-Specific
Event Notification", June 2002
11. Specific Transport Mechanism
The following specific transport mechanisms could be considered for
transporting EAP session policy information:
McCann Expires July 8, 2013 [Page 16]
Internet-Draft Session Policy Framework using EAP January 2013
. IP-CAN (IP (Internet Protocol) Connectivity Access Network) via
IKEv2 (Internet Key Exchange version 2) as per RFC 5269.
. PPP (Point-to-Point Protocol) as per RFC 2284.
. wired IEEE 802 LANs (IEEE-802.1X).
. IEEE 802.11 wireless LANs (IEEE-802.11).
Using any of these transport protocols, EAP messages are sent at a
lower protocol layer than the SIP messages themselves, which are
typically sent at the application layer.
12. Acknowledgments
The authors would like to acknowledge Andrew Allen and Nancy Cam-
Winget for their contributions to this document.
This document was prepared using 2-Word-v2.0.template.dot.
13. Authors' Addresses
Stephen McCann
Research in Motion
200 Bath Road
Slough
Berkshire, SL1 3XE, UK
Email: smccann@rim.com
Mike Montemurro
Research in Motion
Mississauga
Ontario, Canada
Email: mmontemurro@rim.com
McCann Expires July 8, 2013 [Page 17]
