Internet DRAFT - draft-greco-sipping-roaming

draft-greco-sipping-roaming






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.


   <?xml version="1.0"?>
   <!-- token building request compiled by the VSP of the user
   bob@example.com. The request contains the ID attribute with the
   identifier of the request, the IssueInstant attribute with the
   time instant of issue of the request expressed in UTC form, the
   Issuer element with the domain name of the service provider, the
   Subject element with the identifier of the user, the conditions
   element with the start time and the expiration time of the token
   in the NotBefore and NotOnOrAfter attributes in UTC form, the user
   QoS class -->
   <req:token_building_request
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:cond="http://www.tti.unipa.it/~silvana/tokencondition"
    xmlns:pt="http://www.tti.unipa.it/~silvana/"
    xmlns:req="http://www.tti.unipa.it/~silvana/requesttype"
    xsi:schemaLocation="http://www.tti.unipa.it/~silvana/requesttype
    token_building_request.xsd"
    ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc" Version="2.0"
    IssueInstant="2006-02-01T00:46:02Z">
    <saml:Issuer>serviceprovider.example.com</saml:Issuer>
    <saml:Subject>
     <saml:NameID
     Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
      bob@example.com
     </saml:NameID>
    </saml:Subject>
    <saml:Conditions NotBefore="2006-02-01T00:55:02Z"
     NotOnOrAfter="2006-03-01T00:55:02Z">
     <saml:Condition xsi:type="cond:condition_profileType">
      <cond:UserProfile>
       <cond:UserClass>Gold</cond:UserClass>
      </cond:UserProfile>
     </saml:Condition>
    </saml:Conditions>
   </req:token_building_request>


               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.

   <?xml version="1.0"?>
   <!DOCTYPE saml:Assertion>
   <!--  Roaming assertion example. The assertion element contains the
   value of the assertion identifier in its ID attribute and the time



Greco Polito & Schulzrinne  Expires January 10, 2008           [Page 13]

Internet-Draft      AAA and billing of Roaming Users           July 2007


   instant of issue of the assertion in the IssueInstant attribute.
   The assertion contains the Issuer element with the guarantor
   identifier; the Signature with information about the method and the
   algorithms used, the digest value, the signature value and the
   certificate of the guarantor; the Subject with the user identifier;
   the Conditions that stores the token lifetime information; the
   Statement with the VSP domain name and the user profile -->
   <saml:Assertion xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
   xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
   xmlns:tk="http://www.tti.unipa.it/~silvana/"
   xmlns:tkc="http://www.tti.unipa.it/~silvana/tokencondition"
   ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc"
   IssueInstant="2006-02-01T00:50:02Z" Version="2.0"
   xsi:schemaLocation="http://www.tti.unipa.it/~silvana/
   roaming_statementType.xsd">
     <saml:Issuer>guarantor.example.com</saml:Issuer>
     <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
       <SignedInfo>
        <CanonicalizationMethod
        Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
        <SignatureMethod
        Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
        <Reference>
           <Transforms>
             <Transform
   Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
           </Transforms>
           <DigestMethod
           Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
           <DigestValue>UmhxeI9DkkQU0iVs4FfiXYvTkMQ=</DigestValue>
        </Reference>
       </SignedInfo>
       <SignatureValue>jNFui.........
       </SignatureValue>
       <KeyInfo>
        <X509Data>
         <X509Certificate>MIIE...........
         </X509Certificate>
        </X509Data>
       </KeyInfo>
     </Signature>
     <saml:Subject>
       <saml:NameID
       Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
        bob@example.com
       </saml:NameID>
     </saml:Subject>



Greco Polito & Schulzrinne  Expires January 10, 2008           [Page 14]

Internet-Draft      AAA and billing of Roaming Users           July 2007


     <saml:Conditions NotBefore="2006-02-01T00:55:02Z"
     NotOnOrAfter="2006-03-01T00:55:02Z">
     </saml:Conditions>
     <saml:Statement xsi:type="tk:roaming_statementType">
       <tk:ServiceProviderID>
       serviceprovider.example.com
       </tk:ServiceProviderID>
       <tk:policy_info>
           <tkc:UserProfile>
             <tkc:UserClass>Gold</tkc:UserClass>
           </tkc:UserProfile>
       </tk:policy_info>
     </saml:Statement>
   </saml:Assertion>


                  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.


<?xml version="1.0" encoding="UTF-8"?>
<ContractOffer xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <IAP_ID>IAP.example.com</IAP_ID>
        <timestamp>2007-02-28T23:20:50.52Z</timestamp>
        <cost costPerUnitTime="6" initialCost="250" timeUnitSize="6000">
                <currency currency="USD" currencyDivisor="1000" namespace="ISO.4217"/>
        </cost>
</ContractOffer>




                   Figure 7: Contract offer XML example



<?xml version="1.0" encoding="UTF-8"?>
<ChargingAuthorization xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <ContractOffer>
                <IAP_ID>IAP.example.com</IAP_ID>
                <timestamp>2007-02-28T23:20:50.52Z</timestamp>
                <cost costPerUnitTime="6" initialCost="250" timeUnitSize="6000">
                        <currency currency="USD" currencyDivisor="1000" namespace="ISO.4217"/>
                </cost>
        </ContractOffer>
        <UserSignature>.....</UserSignature>
</ChargingAuthorization>




                  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


<Receipt xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <ContractOffer>
                <IAP_ID>IAP.example.com</IAP_ID>
                <timestamp>2007-02-28T23:20:50.52Z</timestamp>
                <cost costPerUnitTime="6" initialCost="250" timeUnitSize="6000">
                        <currency currency="USD" currencyDivisor="1000" namespace="ISO.4217"/>
                </cost>
        </ContractOffer>
        <VSPSignature>.....</VSPSignature>
        <VSPCertificate>....</VSPCertificate>
</Receipt>




                       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


   <?xml version="1.0"?>
   <!-- definition of the condition_profileType -->
   <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://www.tti.unipa.it/~silvana/tokencondition"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    elementFormDefault="qualified">
    <xsd:import namespace="urn:oasis:names:tc:SAML:2.0:assertion"
     schemaLocation="saml-schema-assertion-2.0.xsd"/>
   <xsd:complexType name="condition_profileType">
     <xsd:complexContent>
      <!-- extension of the ConditionAbstractType with the
       UserProfile element which contains the UserClass element -->
      <xsd:extension base="saml:ConditionAbstractType">
       <xsd:sequence>
        <xsd:element name="UserProfile">
         <xsd:complexType>
          <xsd:sequence>
           <xsd:element name="UserClass">
            <xsd:simpleType>
             <xsd:restriction base="xsd:string">
              <xsd:enumeration value="Gold"/>
              <xsd:enumeration value="Bronze"/>
              <xsd:enumeration value="Silver"/>
             </xsd:restriction>
            </xsd:simpleType>
           </xsd:element>
          </xsd:sequence>
         </xsd:complexType>
        </xsd:element>
       </xsd:sequence>
      </xsd:extension>
     </xsd:complexContent>
    </xsd:complexType>
   </xsd:schema>


            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


   <?xml version="1.0"?>
   <!-- definition of the token_building_request element that describes
   the token building request -->
   <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://www.tti.unipa.it/~silvana/requesttype"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:cond="http://www.tti.unipa.it/~silvana/tokencondition"
    xmlns="http://www.tti.unipa.it/~silvana/requesttype"
    elementFormDefault="qualified">
    <xsd:import namespace="urn:oasis:names:tc:SAML:2.0:assertion"
     schemaLocation="saml-schema-assertion-2.0.xsd"/>
    <xsd:import namespace="urn:oasis:names:tc:SAML:2.0:protocol"
     schemaLocation="saml-schema-protocol-2.0.xsd"/>
    <xsd:import
     namespace="http://www.tti.unipa.it/~silvana/tokencondition"
     schemaLocation="condition_profileType.xsd"/>
    <xsd:element
    name="token_building_request" type="token_buildingReqType"/>
     <xsd:complexType name="token_buildingReqType">
      <xsd:complexContent>
      <!-- Extension of the SAML RequestAbstractType with the
       Subject element and the Conditions element -->
       <xsd:extension base="samlp:RequestAbstractType">
        <xsd:sequence>
         <xsd:element ref="saml:Subject"/>
         <xsd:element ref="saml:Conditions"/>
        </xsd:sequence>
       </xsd:extension>
      </xsd:complexContent>
     </xsd:complexType>
   </xsd:schema>


            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


<?xml version="1.0"?>
<!-- Definition of the roaming_statementType  -->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 targetNamespace="http://www.tti.unipa.it/~silvana/"
 elementFormDefault="qualified"
 xmlns="tokenaccess"
 xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
 xmlns:pre="http://www.tti.unipa.it/~silvana/tokencondition">
 <xsd:import namespace="urn:oasis:names:tc:SAML:2.0:assertion"
  schemaLocation="saml-schema-assertion-2.0.xsd"/>
 <xsd:import namespace="http://www.tti.unipa.it/~silvana/tokencondition"
  schemaLocation="condition_profileType.xsd"/>
 <xsd:complexType name="roaming_statementType">
  <xsd:complexContent>
   <xsd:extension base="saml:StatementAbstractType">
    <xsd:sequence>
     <!-- Definition of the ServiceProviderID element having
      saml:NameIDType type  -->
     <xsd:element name="ServiceProviderID" type="saml:NameIDType"/>
     <!-- Definition of the policy_info element having
      condition_profileType type -->
     <xsd:element name="policy_info" type="pre:condition_profileType"/>
    </xsd:sequence>
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>
</xsd:schema>


        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


<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
 <element name="ContractOffer">
        <complexType>
          <sequence>
                <xs:element name="IAP_ID"></xs:element>
                <xs:element name="timestamp"></xs:element>
                <element name="cost">
                <complexType>
                 <attribute default="0" name="initialCost" type="unsignedLong" use="optional"/>
                 <attribute default="0" name="costPerUnitTime" type="unsignedLong" use="optional"/>
                 <attribute default="0" name="timeUnitSize" type="unsignedLong" use="optional"/>
                 <attribute default="0" name="costPerUnitData" type="unsignedLong" use="optional"/>
                 <attribute default="0" name="dataUnitSize" type="unsignedLong" use="optional"/>
            </complexType>
                </element>
                <element name="currency">
                <complexType>
                 <attribute name="namespace" type="string" use="required"/>
                 <attribute name="currency" type="string" use="required"/>
                 <attribute name="currencyDivisor" type="unsignedLong" use="required"/>
                </complexType>
                </element>
          </sequence>
        </complexType>
 </element>
</schema>




                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]