From: http://www.ietf.org/internet-drafts/draft-greco-sipping-roaming-01.txt
Title: Authentication, Authorization, Accounting and Billing of Roaming Users using SAML
Reference: IETF Network Working Group, Internet Draft 'draft-greco-sipping-roaming-01'
Date: July 9, 2007
I-D Tracker: http://ietfreport.isoc.org/idref/draft-greco-sipping-roaming/
Earlier title: SIP and SAML Roaming Profile
http://xml.coverpages.org/draft-greco-sipping-roaming-00.txt
See also:
IETF Session Initiation Protocol (SIP) Working Group
http://www.ietf.org/html.charters/sip-charter.html
Session Initiation Protocol Status Pages
http://tools.ietf.org/wg/sip/
Security Assertion Markup Language (SAML)
http://xml.coverpages.org/saml.html
==============================================================================
Network Working Group S. Greco Polito
Internet-Draft H. Schulzrinne
Intended status: Standards Track Columbia University
Expires: January 10, 2008 July 9, 2007
Authentication, Authorization, Accounting and Billing of Roaming Users
using SAML
draft-greco-sipping-roaming-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 1]
Internet-Draft AAA and billing of Roaming Users July 2007
Abstract
Roaming services allow users that have a contract with a voice
service provider to use access resources owned by other providers
known as internet access providers. This draft proposes a token-
based Authentication, Authorization, Accounting (AAA) and billing
model for roaming users supporting the Session Initiation Protocol
(SIP). It also introduces a protocol solution for the proposed model
that is based on the Security Assertion Markup Language (SAML)
protocol and the Hypertext Transfer Protocol (HTTP).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Token provisioning . . . . . . . . . . . . . . . . . . . . 4
1.2. Access authentication and authorization . . . . . . . . . 5
1.3. Accounting and billing . . . . . . . . . . . . . . . . . . 5
1.4. Content . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol description . . . . . . . . . . . . . . . . . . . . . 7
3.1. User behavior . . . . . . . . . . . . . . . . . . . . . . 9
3.2. VSP behavior . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Guarantor behavior . . . . . . . . . . . . . . . . . . . . 10
3.4. IAP behavior . . . . . . . . . . . . . . . . . . . . . . . 10
4. Roaming SAML profile . . . . . . . . . . . . . . . . . . . . . 11
4.1. Token building request and response . . . . . . . . . . . 11
4.2. SAML roaming assertion . . . . . . . . . . . . . . . . . . 13
5. Accounting and billing . . . . . . . . . . . . . . . . . . . . 16
5.1. Billing without price negotiation . . . . . . . . . . . . 16
5.1.1. Post-paid billing without price negotiation . . . . . 16
5.1.2. Pre-paid billing without price negotiation . . . . . . 17
5.2. Pre-paid billing with price negotiation . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. XML schemas . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. XML schema of the Condition element . . . . . . . . . . . 23
7.2. XML schema of the token building request . . . . . . . . . 24
7.3. XML schema of the Statement element . . . . . . . . . . . 25
7.4. XML schema of the contract offer . . . . . . . . . . . . . 26
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 32
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 2]
Internet-Draft AAA and billing of Roaming Users July 2007
1. Introduction
The authentication, authorizzation, accounting (AAA) and billing of
roaming VoIP users requires interaction between voice service
providers (VSP) contracted by users, and Internet access providers
(IAP) that own access resources. We propose an AAA and billing model
in which we want to leverage the business, billing and trust
relationship that users have with their VSPs to give the customers of
VoIP users roaming access to various wireless and wired internet
access providers, both traditional carriers, such as 3G providers, as
well as local hotspot providers. We propose an AAA and billing
solution in which VSPs provide their users with tokens containing all
the information that IAPs need for verifying their authorization and
activating the accounting and billing procedures. These tokens are
issued and signed by a third party, called guarantor, which also
provides accounting and billing mediation services. Using the model
proposed in this draft, by adding a smaller set of guarantors, IAPs
that do not know VSPs, and vice versa, can offer services to
customers of VSPs. Figure 1 shows the trust model of the AAA
solution proposed in this document.
+------------+ +-----------+ +-----------+
| internet | trust | | trust | voice |
| access |<------------->| guarantor |<------------->| service |
| provider | relationship | | relationship | provider |
+------------+ +-----------+ +-----------+
^
|
|
+------------+ |
| | trust |
| user |<------------+
| | relationship
+------------+
Figure 1: trust model
The role of the guarantor is somewhat similar to that of a
clearinghouse for settlement and billing, but it differ in
authorization. While clearinghouses are used for authorizing users'
calls, the guarantor provides authorization for the use of access
network resources. One of the main protocols for clearinghouse-
based models is the Open Settlements Protocol (OSP) [OSP]. OSP
inroduces a token-based authorization model for interdomain calls in
which telephony operators can ask a clearinghouse for tokens proving
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 3]
Internet-Draft AAA and billing of Roaming Users July 2007
the right of their users to place calls toward some destination. In
this draft, we extend the concept of tokens introduced by OSP,
focusing on the authorization and authentication of roaming users
instead of the authorization of calls. We define a token with a long
lifetime that can be held by users and allows them to be
authenticated and authorized to use access network resources from
internet access providers that they do not mantain a business
relationship with. We propose an authentication and authorizaion
model in which users can provide the IAPs with their tokens. The
model does not require interaction between IAPs and VSPs of visiting
users for the verification of the user's identity and authorization
profile and avoids run home AA (authentication and authorization)
messaging that may significaly increase the AA delay if the access
network is far from the infrastructure of the VSP where the user's
credentials are stored. In the model, security associations between
IAPs and VSPs are not required.
The token-based AAA and billing solution proposed in this draft is
composed of the procedures that allow users to ask for and obtain
tokens from their VSPs, which are called token provisioning
procedures, the procedures for getting access authentication and
authorization using the token, and the ones for accounting and
billing.
1.1. Token provisioning
The procedures that allow users to obtain tokens are called token
provisioning procedures and involve users, VSPs and guarantor. Users
activate these by a token request to their VSP. VSPs interact with
the guarantor in order to build tokens for their users, providing the
guarantor with information about users such as their authorization
profiles. The guarantor uses this information to issue and sign AAA
and billing tokens. The signature guarantees data origin, integrity
and non repudiation of the token. The set of procedures performed by
VSPs and guarantor for issuing tokens are called token building
procedures. In Section 4 , we provide a complete description of the
AAA and billing token and the messages used for the communication
between VSPs and guarantor based on SAML. SAML [saml-core-2.0-os] is
an OASIS protocol for the description and exchange of security
information between partners. We define a new SAML profile called
roaming profile. This SAML roaming profile describes the set of
extensions to the SAML protocol that allows to use it as description
protocol for the AAA and billing model of roaming users introduced in
this draft.
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 4]
Internet-Draft AAA and billing of Roaming Users July 2007
1.2. Access authentication and authorization
The token-based access authentication and authorization consist of
procedures that allow users to provide the access network with their
tokens when they ask for access to the Internet and the access
network to verify if tokens are valid.
1.3. Accounting and billing
The accounting and billing procedures allow to charge VoIP users for
the access network resources used. In this draft, three accounting
and charging models are introduced, showing the differences between
pre-paid and post-paid billing.
1.4. Content
The remained of the document is organized as follows. In Section 2
we provide the terminology used in the subsequent sections. In
Section 3 we introduce the token-based AAA and billing model and we
describe the behavior of users, voice service providers, guarantors
and internet access providers for token provisioning and token-based
access authentication and authorization. In Section 4 we introduce
the SAML roaming profile. Specifically, Section 4.1 defines the
rules for the SAML-based description of the messages used by VSPs and
the guarantor in the token building phase. Section 4.2 introduces
the SAML roaming assertion that is a SAML-based description of the
token. Section 5 focus on the issue regarding accounting and
billing. It introduces pre-paid and post-paid charging models and
the concept of price negotiation between users and IAPs for payment
of Internet access resources. In Section 6 we provide our security
considerations about the protocol proposed. Section 7 contains
details about the extensions to the SAML elements that support the
SAML roaming profile and the description of the messages used for
price negotiation between IAPs and users.
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 5]
Internet-Draft AAA and billing of Roaming Users July 2007
2. Terminology
Voice Service Provider (VSP): provider of multimedia voice
services (VoIP services).
Internet access provider (IAP): provider of access network
resources such as wireless local access networks and 3G networks.
Guarantor: provider of mediation services for AAA and billing.
User: customer contracting with a VSP for obtaining VoIP and
roaming services.
Security Assertion Markup Language (SAML): set of specifications
describing security assertions that are encoded in Extensible
Markup Language (XML) [XML], profiles for attaching the assertions
to various protocols and frameworks, the request/response protocol
used to obtain the assertions, and bindings of this protocol to
various transfer protocols [saml-glossary-2.0-os].
SAML assertion: piece of data produced by a SAML authority
regarding either an act of authentication performed on a subject,
attribute information about the subject, or authorization data
applying to the subject with respect to a specified resource
[saml-glossary-2.0-os]
AAA and billing token or roaming token: element asserting the
user's right to access the network. It contains user
authorization information and information needed to the IAP for
activating the accounting and billing procedures.
Roaming assertion: SAML-based description of the token.
SAML Simple Object Access Protocol (SOAP) binding: definition on
how to use SOAP to send and receive SAML requests and responses.
This binding has protocol-independent aspects, but also calls out
the use of SOAP over HTTP [saml-binding-2.0-os].
Roaming SAML profile: set of constraints and rules for using the
SAML protocol and the SAML assertion capability in the roaming AAA
and billing context of use.
For the SIP terminology, see [RFC3261].
For the overall SAML terminology, see [saml-glossary-2.0-os].
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 6]
Internet-Draft AAA and billing of Roaming Users July 2007
3. Protocol description
Figure 2 shows the messages exchanged between user, VSP and guarantor
for the token provisioning procedure, and the one between user, IAP,
guarantor and VSP for token-based AA. The token provisioning
procedure is performed in the following steps:
1. The user starts the procedure sending a token request to its VSP,
using an HTTP GET request.
2. When the VSP receives a token request, it asks the user for its
authentication and authorization credentials. The user's
authentication avoids that malicious subjects obtain tokens
impersonating authorized users. In this scenario, the HTTP
digest method is used for user authentication and SIP credentials
may be reused.
3. The user resends its token request including the information
required for its authentication in the HTTP GET message.
4. The VSP verifies the user's identity. If the user authentication
is successful, the VSP sends a token building request to the
guarantor, asking it to issue and sign a token for its user.
This request contains information that the guarantor needs for
building the token such as the user's profile and the token
length (see Section 4.1 for the description of this request).
5. The guarantor builds and signs the token and returns it to the
VSP. The token is described using SAML (see Section 4.2) and
inserted in a token building response. Section 4.1 describes the
token.
6. The VSP, extracts the token from the token building response, and
sends it to the user in an HTTP 200 OK response.
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 7]
Internet-Draft AAA and billing of Roaming Users July 2007
IAP user VSP guarantor
| | | |
| token provisioning procedure |
|<==========================================================>|
| | | |
| |1)Token request | |
| | (HTTP GET) | |
| |------------------->| |
| | | |
| |2)407 Proxy | |
| | Authent. Req | |
| |<-------------------| |
| | | |
| |3)Token request | |
| | (HTTP GET: | |
| |Proxy-Authorization)| |
| |------------------->| |
| | |4)Token building |
| | | request |
| | | (HTTP: SAML-token |
| | | building request) |
| | |-------------------->|
| | | |
| | |5)Token building |
| | | response |
| | | (HTTP:SAML-token |
| | | building response) |
| | |<--------------------|
| |6)Token Response | |
| | (HTTP 200 OK) | |
| |<-------------------| |
| | | |
| token-based AA procedure |
|<==========================================================>|
| | | |
|1)Token-based | | |
| Access Request | | |
|<----------------| | |
| | | |
|2)Access Response| | |
|---------------->| | |
| | | |
Figure 2: messaging for token provisioning and token-based AAA
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 8]
Internet-Draft AAA and billing of Roaming Users July 2007
The user stores the token received and uses it to obtain AA from IAPs
visited late. The token-based AA of roaming users requires
interaction between the user and the IAP:
1. The user sends a token-based access request containing the token
to the IAP asking for access to the Internet. The token has to
be sent using a secure transport channel to prevent malicious
subjects from intercepting the flow between user and access
network and make copies of the token.
2. The IAP verifies the validity of the token and returns a response
containing the authorization verification result to the user.
The protocols used to provide the access network with the user's
token may depend on the access network technology. In all cases, a
secure channel has to be build between user and access network to
provide the access network with the token. For example, if the
access network technology supports EAP (Extensible Authentication
Protocol) [RFC3748], the EAP-TTLS [draft-funk-eap-ttls-v1-01] method
may be used to constract the secure channel.
3.1. User behavior
The user supports HTTP and asks the VSP for the token using an HTTP
GET message. The URL of the GET message points to a location where
the VSP stores the user's token. The token request causes the
activation of the HTTP digest authentication procedure between user
and VSP. If the authentication is successful, the VSP provides the
user with the token in a HTTP 200 OK message. The user will use this
token until its expiration time to ask IAPs for access to the
Internet.
3.2. VSP behavior
The VSP uses HTTP to communicate with the user and the guarantor.
Each time the VSP receives a token request, it verifies the user
identity and, if the authentication is successful, it verifies if the
last token issued for the user is expired (it is assumed that the VSP
maintains a local copy of the token) and, if the last issued token is
expired, the VSP activates the token building procedure asking the
guarantor for a new signed token with a token building request. The
VSP is the entity that maintains a contract with the user and knows
his authorization profile. The VSP includes the user identity, the
user's authorization profile, and the token lifetime in the token
building request. It structures this request in the format of SAML
request using the set of extensions defined in Section 4.2. When the
VSP receives the token from the guarantor, it sends it to the user in
the body of the 200 OK response to the HTTP GET request.
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 9]
Internet-Draft AAA and billing of Roaming Users July 2007
3.3. Guarantor behavior
The guarantor builds and signs tokens for users that are customers of
VSPs. When the guarantor receives the token building request, it
builds the token, inserting the information contained in the request
along with its identifier, the domain name of the VSP, the signature
and its certificate. The guarantor signs the token using its private
key. The signature guarantees integrity, data origin and non
repudiation of the token. The guarantor composes the token in the
form of a SAML assertion as described in Section 4.2 and returns it
to the VSP. It uses the SAML assertion response specifications for
describing the token building response (see Section 4.1 for details).
The guarantor is responsible for paying the IAPs that authorize users
on the basis of its signature on the tokens. The guarantor is
reimbursed by the VSPs which are the only entities that hold the
users' credentials and can charge them (see Section 5 for details
about accounting and billing).
3.4. IAP behavior
After receiving a token from a visitng user, the IAP verifies the
token integrity. The IAP uses the guarantor's public key carried in
the token for the verification. If the token is not corrupted, the
IAP verifies its expiration time. If the token has not expired, the
IAP allows the user to access the network. The digital signature
guarantees non repudiation of the token and gives the right to ask
the guarantor for the payment of the access resources used by
visiting users to the IAPs. IAPs are not interested in knowing the
identity of the VSP of visiting users because the guarantor provides
the payment for the access resources instead of the VSP.
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 10]
Internet-Draft AAA and billing of Roaming Users July 2007
4. Roaming SAML profile
SAML defines a framework for the exchange of security information
about a subject between partners called requesting, asserting and
relying parties. The asserting party is the entity that produces an
authentication and authorization assertion about a subject when
required by the requesting party, while the relying party uses the
assertion for authorizing the subject.
This draft defines a new SAML profile, called roaming SAML profile.
It defines a set of specifications that allows to use SAML for the
description of the token and the token building request and response
introduced above.
In the SAML roaming profile, the VSPs assume the role of SAML
requesting parties, the guarantor the one of asserting party, and
IAPs the one of relying parties. Below, we will call the token
described using SAML "roaming assertion" and we will assume that user
and VSP support SIP (Session Initiation Protocol) [RFC3261].
4.1. Token building request and response
The token building request is the message used by the VSP for asking
the guarantor for the token (see step 3 of the token provisioning
procedure of Figure 2). It is structured as a SAML request and is
described using the following elements:
o The Issuer. This SAML element contains the identifier of the
entity generating the request message. Here, it contains the
VSP's domain name.
o The Subject. It contains the identifier of the subject of the
assertion and it is set to the SIP AoR of the user in the token
building request.
o The Conditions. This element allows the SAML requesting party to
impose conditions limiting the validity and/or use of the
assertion. Here, it is used by the VSP to provide the guarantor
with information about the assertion lifetime and the user
profile. For the description of the token lifetime we use the
SAML NotBefore and NotOnOrAfter attributes of the assertion
element. The first is the start time of the token, the second the
expiration time of the token. For the description of the user
profile and its inclusion in the Conditions element, we propose an
extension of the SAML ConditionAbstractType described in
Section 7.1.
Figure 3 shows an example of the token building request described
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 11]
Internet-Draft AAA and billing of Roaming Users July 2007
using the elements introduced above. See Section 7.2 for the
description of the XML schema of this request.
serviceprovider.example.com
bob@example.com
Gold
Figure 3: XML token building request example
The guarantor delivers the token to the VSP into the token building
response (see step 4 of the assertion provisioning procedure of
Figure 2). The guarantor uses the SAML description rules for a
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 12]
Internet-Draft AAA and billing of Roaming Users July 2007
response to a generic SAML query message [saml-core-2.0-os] to
contruct the token building response, mapping this response in the
SAML Response element. The SOAP SAML binding described in
[saml-binding-2.0-os] is used for the transport of the token building
request and response. It defines how to use HTTP and SOAP to send
and receive SAML requests and responses.
4.2. SAML roaming assertion
We call the token described using the SAML assertion
[saml-core-2.0-os] specifications and the set of extensions provided
in this section "roaming assertion". The token is mapped in the SAML
Assertion element and its content is described using the following
SAML elements:
o The Issuer. In a generic SAML assertion, this element contains
the identifier of the identity that is making the claim in the
assertion and it is set with the guarantor identifier in a
roaming-assertion.
o The Signature. This element contains the signature provided by
the guarantor. Following the OASIS specifications
[saml-core-2.0-os] [saml-sec-consider-2.0-os] for this element,
the guarantor computes it using the XML signature specifications
[xmldsig].
o The Subject. It contains the SIP AoR of the user which is the
subject of the statement in the roaming assertion.
o The Conditions. In a generic SAML assertion, this element
contains information that must be evaluated by the relying party
for the verification and use of the assertion. Here, the
NotBefore and NOtOnOrAfter attributes of this element are used to
describe the start and expiration time of the token.
o The Statement. It is an SAML extension point defined for allowing
the use of SAML in new contexts. This draft defines an extension
of the SAML type of the Statement element in order to include the
domain name of the VSP and information about the user profile in
this element . The XML schema of the extension to the type of
Statement element is provided in Section 7.3.
Figure 4 shows an example of the roaming assertion.
guarantor.example.com
UmhxeI9DkkQU0iVs4FfiXYvTkMQ=
jNFui.........
MIIE...........
bob@example.com
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 14]
Internet-Draft AAA and billing of Roaming Users July 2007
serviceprovider.example.com
Gold
Figure 4: XML roaming assertion example
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 15]
Internet-Draft AAA and billing of Roaming Users July 2007
5. Accounting and billing
The accounting and billing model proposed in this document delegates
to the guarantor the provisioning of accounting and billing
intermediation services between IAPs and VSPs. The guarantor is
responsible for paying the IAPs that provide roaming users with their
services, while the guarantor is reimbursed by the VSPs of the users.
The digital signature on the token guarantees non-repudiation of the
token. Signed tokens give the IAPs the right to ask the guarantor
for the payment of the resources provided to visiting users.
IAPs have to issue accounting records with information about the
amount of resources for which a user has to be charged in order to
ask for and receive payment. In the following three billing models
are proposed. The first two models (see Section 5.1) are based on
the assumption that VSPs, IAPs and guarantor define the price of the
roaming service in advance and that users are provided with
information about this price when they contract with their VSPs. The
third model introduced (see Section 5.2) allows a per-session
negotiation of the price of the service between IAPs and visited
users. This method allows each IAP to offer its own pricing plan to
visiting users.
5.1. Billing without price negotiation
The billing without negotiation of the price of the roaming service,
is based on the assumpition that users know this price when they asks
IAPs for access to the Internet. This avoids any exchange between
IAPs and users for the negotiation of the price of the service at the
connection time. The following subsections describe two models for
post-paid and pre-paid billing without price negotiation,
respectively.
5.1.1. Post-paid billing without price negotiation
In post-paid billing models, the charging procedures are activated
after the use of resources or services. In the roaming context, if a
post-paid billing method is used, users are allowed to access the
Internet without controlling in advance if they can pay for the
services used, i.e., without controlling the availability of money
from the user before providing him with access network resources.
The main advantage of post-paid billing methods is that they allow to
charge users for the real amount of resources used on the basis of
accounting records provided by the IAPs.
The main drawback of post-paid methods is the risk of insolvency of
users. It is possible implement per-timeslot charging methods to
reduce this risk. When per-timeslot methods are used, the session is
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 16]
Internet-Draft AAA and billing of Roaming Users July 2007
divided in slots having a pre-defined length and the accounting and
charging procedures are activated at the end of each timeslot. This
way, the risk of insolvency of the user depends on the length of the
timeslot and may be reduced using short timeslots. On the other
hands, short timeslots increase the accounting and charging signaling
and processing overhead.
The token-based access model introduced in the previous sections
support both per-session and per-timeslot post-paid methods. In the
per-session method, IAPs issue accounting records for the total
length of the connection session of visiting users and send them to
the guarantor. The guarantor provides these records to the VPSs of
the users that activates the charging procedures. Similarly, if a
per-timeslot method is used, IAPs issue accounting records for each
timeslot of connection and provide these records to the guarantor at
the end of each timeslot.
5.1.2. Pre-paid billing without price negotiation
In pre-paid billing the user is charged before using the resources.
Pre-paid billing solutions have the advantage that they guarantee
payment from users for the resources used. They suffer from the
disadvanage that users may be charged for more than the resource
really used because the billing is performed before having
information about the amount of resources used on the basis of a
priori agreements.
In pre-paid billing, the connection sessions are usually divided into
timeslots (as in the per-timeslot post-paid solution) and the user is
charged for each timeslot of connection in advance. In the pre-paid
billing, IAPs issue a request for user charging at the beginning of
each session slot. This request is sent to the guarantor which
forwards it to the user's VSP. The user is charged for each session
slot in advance and the system does not assume risks for user
insolvency. The procedures for the payment of the IAPs from the
guarantor and the one of the guarantor from the VSPs are independent
on the procedure for charging the user and may be performed at any
time depending on settlements between IAPs, VSPs and guarantor.
Figure 5 shows the messaging between IAP, guarantor and VSP for both
the pre-paid and post-paid billing models introduced in this section.
The messaging is composed of a charging request issued by the IAP and
sent to the guarantor which forwards it to the VSP. In the case of
post-paid billing IAPs include in the charging request the accounting
records describing the amount of resources used by the user with
information such as the amount of data exchanged by the user and the
length of the connection. In the case of pre-paid billing, the
charging request is sent at the beginning of the connection or at the
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 17]
Internet-Draft AAA and billing of Roaming Users July 2007
beginning of each time slot and the user is charged based on the
length of the connection slot.
user IAP guarantor VSP
| | | |
| |1)charging request/ | |
| |(accounting records)| |
| |------------------->| |
| | | |
| | | 2)charging request/ |
| | |(accounting records) |
| | | ------------------->|
| | | |
| | 3)charging response |
| |<-------------------|<--------------------|
Figure 5: Messaging for pre-paid and post-paid billing without price
negotiation
5.2. Pre-paid billing with price negotiation
The pre-paid and post-paid solutions introduced above assume that
VSP, IAP and guarantor have defined the price of the roaming service
and that users know this price before asking a IAP for access to the
Internet. This section describes a method that allows IAPs to have
independent price plans and inform visiting users about their price
plans at the connection time following the model proposed in
[draft-jennings-sipping-pay-05] for billing of multi-provider VoIP
calls. The charging method proposed requires that users are provided
with a pair of public and private key, and that VSPs are provided
with a public certificate issued by the guarantor. The model
consists of the following interactions between user, IAP and VSP:
o The IAP sends a contract offer to the user after receiving an
access request with a token and verifying the validity of this
token. This offer contains the description of the price plan of
the IAP, the identifier of the IAP and a timestamp element with
the issuing instant of the offer.
o The user may accept the offer or reject it. If he accepts the
offer, he signs the offer received with his private key and sends
the signed offer to its VSP. The payment offer signed by the user
assumes the meaning of charging request from the user to its VSP.
The user uses this message to ask its VSP to charge him following
the charging rules described in the message (amount of anticipated
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 18]
Internet-Draft AAA and billing of Roaming Users July 2007
cost, per-unit cost, etc..) See Figure 13 for the description of
the contract offer.
o The VSP that receives a charging request charges the user on the
basis of the content of the offer and returns a charging receipt
to the IAP. The charging receipt is build adding a digital
signature and the certificate of the VSP to the original contract
offer. The VSP extracts the contract offer from the charging
request message.
o When the IAP receives the receipt, he can verify its freshness
through the timestamp of the contract offer encapsulated in it.
The certificate carried in the message guarantees that the VSP is
trusted by the guarantor and allows to verify data origin and
integrity of the receipt. If the verification of the receipt is
successful, the IAP allows the user to access to the network.
user IAP guarantor VSP
| | | |
| | | |
| | | |
|1)contract offer | | |
|<----------------| | |
| | | |
|2)charging requ. | | |
|---------------->| |
| | 3)charging requ. |
| |----------------------------------------->|
| | | |
| | 4)receipt |
| |<-----------------------------------------|
| | | |
|5)access allowed | | |
|<----------------| | |
Figure 6: Messaging for charging with cost negotiation
The contract offer contains a timestamp element, the identifier of
the IAP and its price plan. The timestamp is used for avoiding
replay attacks and for the verification of the freshness of the
receipt issued by the VSP. The IAP identifier allows the VSP to
identify the IAP to which sending the receipt. The cost plan
describes the cost of the service. XML examples of a contract offer,
a charging request and a receipt are provided in Figure 7 (see
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 19]
Internet-Draft AAA and billing of Roaming Users July 2007
Figure 13 for the XML schema of the contract offer), Figure 8 and
Figure 9, respectively.
IAP.example.com
2007-02-28T23:20:50.52Z
Figure 7: Contract offer XML example
IAP.example.com
2007-02-28T23:20:50.52Z
.....
Figure 8: Charging request XML example
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 20]
Internet-Draft AAA and billing of Roaming Users July 2007
IAP.example.com
2007-02-28T23:20:50.52Z
.....
....
Figure 9: Receipt XML example
One of the main advantage of the model introduced above is that the
charging is authorized by the user directly.
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 21]
Internet-Draft AAA and billing of Roaming Users July 2007
6. Security Considerations
The security properties of the proposed protocol depend on the
security features of HTTP and SAML. VSPs use the HTTP authentication
features and authenticate users before accepting their token requests
to avoid that malicious subjects impersonating them obtain
assertions. For the same reason the guarantor authenticates VSPs
before accepting their token building requests. VSPs have to
authenticate the guarantor before sending token building requests
because these contain private information about users. VSPs and the
guarantor may use the SAML authentication features described in
[saml-sec-consider-2.0-os]for their mutual authentication. Moreover
they must guarantee confidential transport of the assertion
encrypting the SOAP messages as specified for the SOAP SAML binding
in [saml-sec-consider-2.0-os]. This avoids that users eavesdropping
the conversation can make copies of the assertion. For the same
reason VSPs encrypt the bodies of the 200 OK responses carrying
roaming assertions. The parties involved may use the Transport Layer
Security (TLS) protocol [RFC2246] which allows building secure
communication channels between them.
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 22]
Internet-Draft AAA and billing of Roaming Users July 2007
7. XML schemas
In this section we provide the XML schemas of the elements and types
defined in this draft to support the SAML roaming profile.
7.1. XML schema of the Condition element
As introduced in Section 4.1, the SAML Condition element is used for
describing the token lifetime and the user profile. For the
description of the token lifetime we use the NotBefore and
NotOnOrAfter attributes of this element defined in
[saml-core-2.0-os]. For the description of the user profile, we
define the condition_profileType. It extends the
ConditionAbstractType of the Condition element defined in
[saml-core-2.0-os] and adds the UserProfile element to it. We use
the quality of service class for describing the user profile. The
quality of service class is described using the values Gold, Bronze,
Silver. Figure 10 shows the xml schema of the condition_profileType.
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 23]
Internet-Draft AAA and billing of Roaming Users July 2007
Figure 10: XML schema of the condition_profileType
7.2. XML schema of the token building request
The token building request is described extending the SAML type
RequestAstractType [saml-core-2.0-os] of a generic SAML request. As
described in the XML schema of Figure 11, the extension that we
propose adds the Subject and the Conditions element to the ones of
the RequestAbstractType. The Subject element is used for including
the SIP URI in the request. The Conditions element allows to
introduce the token lifetime and the user profile in the token
building request.
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 24]
Internet-Draft AAA and billing of Roaming Users July 2007
Figure 11: XML schema of the token building request
7.3. XML schema of the Statement element
Figure 12 shows the XML schema of the type of the Statement element
of the roaming assertion. It is obtained as extension of the
StatementAbstractType defined in [saml-core-2.0-os]. It allows to
include in the Statement element of the roaming assertion the domain
name of the VSP, and the policy_info element. This carries
information about the user profile and has the type defined in
Section 7.1.
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 25]
Internet-Draft AAA and billing of Roaming Users July 2007
Figure 12: XML schema of the roaming Statement element type
7.4. XML schema of the contract offer
Figure 13 describes the components of the contract offer introduced
in Section 5.2. This offer has been defined following the model
introduced in [draft-jennings-sipping-pay-05]. The elements of the
offer are the IAP_ID for the description of the IAP identifier, the
timestamp containing the issuing time of the offer, and the cost
element with the description of the cost plan of the IAP. The
description of the cost element is derived from the description of
the homonymous element introduced in [draft-jennings-sipping-pay-05]
(see it for additional details).
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 26]
Internet-Draft AAA and billing of Roaming Users July 2007
Figure 13: XML schema of the contract offer
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 27]
Internet-Draft AAA and billing of Roaming Users July 2007
8. Acknowledgements
The authors thank Hannes Tschofenig for his comments.
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 28]
Internet-Draft AAA and billing of Roaming Users July 2007
9. References
9.1. Normative References
[OSP] European Telecommunications Standards Institute,
"Telecommunications and Internet Protocol Harmonization
Over Networks (TIPHON) Release 4; Open Settlement Protocol
(OSP) for Inter-Domain pricing, authorization and usage
exchange", ETSI Technical Specification ETSI TS 101 321
V4.1.1 (2003-11), 2003.
[RFC2246] Dierks, T. and C. C. Allen, "The TLS Protocol Version
1.0", RFC 2246, January 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol HTTP 1/1", RFC 2616, June 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., and J. Peterson, "Session
Initiation Protocol", RFC 3261, June 2002.
[RFC3748] Fielding, R., Aboba, B., Blunk, L., Vollbrecht, J.,
Carlson, J., and H. Levkowetz, "Extensible Authentication
Protocol (EAP)", RFC 3748, June 2004.
[RFC4187] J. Arkko, J. and H. H. Haverinen, "Extensible
Authentication Protocol Method for 3rd Generation
Authentication and Key Agreement (EAP-AKA)", RFC 4187,
January 2006.
[XML] World Wide Web Consortium, "Extensible Markup Language
(XML) 1.0", W3C XML, February 1998.
[a802.1x] IEEE, "Port-based network access control", IEEE
standard 802.1x, 2001.
[applicationsamlassertionxml]
OASIS Security Services Technical Committee, "application/
samlassertion+xml MIME Media Type Registration", IANA MIME
Media Types application/samlassertion+xml, December 2004.
[saml-binding-2.0-os]
Cantor, S., Hirsch, F., Philpott, R., and E. Maler,
"Binding for the OASIS Security Assertion Markup Language
(SAML) V2.0", OASIS Standard saml-binding-2.0-os,
March 2005.
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 29]
Internet-Draft AAA and billing of Roaming Users July 2007
[saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard saml-core-
2.0-os, March 2005.
[saml-glossary-2.0-os]
Hodges, J., Philpott, R., and E. Maler, "Glossary for
Security Assertion Markup Language (SAML) V2.0", OASIS
Standard saml-glossary-2.0-os, March 2005.
[saml-profiles-2.0-os]
Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra,
P., Philpott, R., and E. Maler, "Profiles for the OASIS
Security Assertion Markup Language (SAML) V2.0", OASIS
Standard saml-profiles-2.0-os, March 2005.
[saml-sec-consider-2.0-os]
Hirsch, F., Philpott, R., and E. Maler, "Security and
Privacy Considerations for the OASIS Security Markup
Language (SAML) V2.0", OASIS saml-sec-consider-2.0-os,
March 2005.
[xmldsig] World Wide Web Consortium, "XML-Signature Syntax and
Processing", W3C Recommendation xmldsig, October 2000.
9.2. Informative References
[draft-funk-eap-ttls-v1-01]
Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS
Authentication Protocol", draft
draft-funk-eap-ttls-v1-01, March 2006.
[draft-ietf-sip-serverfeatures-02]
Rosenberg, J. and H. Schulzrinne, "The SIP Supported
Header", draft draft-ietf-sip-serverfeatures-02,
September 2000.
[draft-jennings-sipping-pay-05]
Jennings, C., Fischl, J., Tschofenig, H., and G. Jun,
"Payment for Services in Session Initiation Protocol
(SIP)", draft draft-jennings-sipping-pay-05,
October 2006.
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 30]
Internet-Draft AAA and billing of Roaming Users July 2007
Authors' Addresses
Silvana Greco Polito
Columbia University
Viale delle Scienze
Palermo, Sicily 90100
Italy
Email: silvana.greco@tti.unipa.it, silvana@cs.columbia.edu
Henning Schulzrinne
Columbia University
450 Computer Science Building
New York, NY 10027
US
Email: hgs@cs.columbia.edu
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 31]
Internet-Draft AAA and billing of Roaming Users July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Greco Polito & Schulzrinne Expires January 10, 2008 [Page 32]