Internet Engineering Task Force H. Behrens
Internet Draft snom technology AG
K. Knuettel
Fraunhofer FOKUS

draft-behrens-sipping-roaming-architecture-00.txt
February 9, 2003
Expires: August, 2004

Interdomain Trust-Relationships for SIP-based Roaming

STATUS OF THIS MEMO

This document is an Internet-Draft and is subject to all
provisions of Section 10 of RFC2026.

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

To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.

Abstract

This draft describes an authentication mechanism which can
be used to enable users of VoIP to globally roam between any
number of ITSPs (Internet Telephony Service Providers)
without needing to have a prior customer or billing
relationship with all of them. This enables profiles and one-
line-billing.
Providers using this authentication mechanism do neither
need full-mesh
trust relationships or roaming agreements with every other
possible provider nor do they need to rely on a centralized
brokerage entity to process calls.
The Home Network (HN), which handles all AAA for a user
attempting to use an ITSP's service is determined through a
unique identifier submitted by the user. This Network Access
Identifier [RFC2486] contains information about the trust
domain or trust realm the user belongs to. Based on a simple
discovery mechanism a provider can establish a trust path to
this home network. Once this is
established, the provider can authenticate the user and
check his credit with the home network. Accounting and rate
information will be sent to the home network for mediation
and processing.

Internet Draft SIP February 8, 2003

1. Introduction..............................................2
2. Requirements..............................................2
3. Architecture..............................................3
4. Terminology...............................................3
5. Conventions used in this document.........................4
6. Security Architecture.....................................4
6.1 Trust Relationships......................................4
6.2 Trust Relationships between Providers and Settlement.....5
7. Actors and Mechanisms.....................................5
7.1 Actors...................................................5
7.2 Mechanisms...............................................5
8. Call Flow.................................................6
10. Bibliography............................................10

1. Introduction

More and more ISPs are beginning to add VoIP to their service
portfolio. The last years have seen the merging of IP-based telephony
and switched line telephony (both mobile and fixed-line) in the sense
that users of VoIP want to be able to call a PSTN or PLMN number as
well as being reachable under a home PSTN or PLMN number. Roaming
between ISPs has not developed to a large degree.
With the advent of voice communication becoming an important service,
this will become more relevant. Users will want to use VoIP for their
telephony and they will want to do this wherever they are located. The
authors believe that one way to address this is to leverage a user’s
existing customer and billing relationship with his home telephony
provider.Users make use of this when signing up for ad-hoc service with
a visited ITSP. The ITSP verifies the existing billing relationship and
receives authorization of a certain amount of credit the home network
is willing to underwrite.
Based on the security architecture described here, mutual trust can be
established and the user can both place VoIP calls through his visited
network as well as being reachable under home number and URI.

2. Requirements

The term ‘Roaming Capability’ has been defined in
[RFC2486].
One aim of this document is to provide an architecture by
which Roaming Capability can be assured by a federation
of independent VoIP providers. In the world of IP-related
protocols little attention has been given to this issue.
Requirements for global roaming for WLAN users have been
described by J. Caron in [CARON.1]. He also outlined a
simple DNS-based method in [CARON.2].
The Roaming Scenario addressed here is as follows:
- The principal with the NAI of alice@biloxi.com sends a REGISTER
request to the SIP registrar of atlanta.com. atlanta.com in this
case is Alice’s ‘Visited Network’ (VN). biloxi.com is her home
network.
- Alice wants to use her VN to place authenticated and secure
VoIP calls.
- Alice wants to be reachable both under her home URI as well as
under a URI assigned by the VN.
- Alice provides her NAI to her VN’s SIP registrar.
- The VN
o asserts that Alice’s Home Network signs Alice’s identity and
authorizes a credit amount greater 0
o asserts that Alice’s HN is a trusted entity
- atlanta.com assigns Alice a temporary Address of Record (AOR) URI
as well as a valid contact address from within its own name space.

H. Behrens, K. Knuettel [Page 2]

Internet Draft SIP February 8, 2003

- Alice registers with her HN using the newly assigned Contact
address as the Contact.
- Alice’s SUA can place outgoing call either under the temporary URI
assigned by the VN or her home URI at biloxi.com.
- Alice is reachable both under her home-AOR as well as the visiting-
AOR. Assuming Alice’s HN provides PSTN break-in, Alice is also
reachable under her telephone number known to her buddies.
- All calls placed by Alice for the duration of this registration are
accounted to Alice’s HN.

3. Architecture

The architecture is based on a model that is user-centric in that it
assumes for each principal or user to have one Home Network with which
he has a valid billing relationship.
This entity can authenticate the user based on his NAI and is willing
to underwrite credit as well as receive CDRs for further settlement.
This HN corresponds to the ‘Authentication Service’ described in
[PETERSON.1]. Basing the architecture on a user-centric model based on
a NAI, greatly reduces the number of billing relationships in a roaming
environment as well allowing incumbent HNs, such PSTN or PLMN providers
[RFC2486], to leverage their existing customer relationships.
New emerging operators can benefit from this, because they can deliver
their services to any user with a valid NAI, knowing that they can bill
the user’s HN up to the credit amount underwritten.
HNs can benefit by charging for this service. This potentially creates
a win-win situation between incumbent operators, who hold the trust and
billing relationships, and emerging ITSPs who wish to be able to
attract as many users as possible, without the financial and
bureaucratic overhead involved in setting up a documented and secure
billing relation with each of their users.

The architecture consists of
1. Peers: entities participating in a roamable VoIP infrastructure
2. Security Architecture: the Security architecture, which
describes the trust relationships as well as security
mechanisms used.
3. Signaling Protocol: Signaling is based on the Session Initiation
Protocol (SIP) [RFC3261].
4. Accounting infrastructure: Both Authentication andAuthorization
are covered by the Security Architecture and/or the Signaling
Protocol. Accounting is based on
- the Authentication and Authorization signed by the HN and
accepted by the VN.
- hub-and-spoke trust relationships from the participating
operators to a Settlement Entity (SE).
This document proposes an architecture, which fulfils these
requirements by making use of pre-existing trust relationships.
The architecture is strongly influenced by work done by J. Peterson
[PETERSON.1] and [RFC3325] on one hand and the work of Aboba et. al
[RFC2486],[RFC2194] on the other hand.

4. Terminology

AAA Authentication, Authorization, Accounting
AOR Address of Record
CDR Call Detail Record
CRM Customer Relationship Management
DoT Domain of Trust
ETSI European Telecommunication Standard Institute
HN Home Network
ITSP Internet Telephony Service Provider
NAI Network Access Identifier

H. Behrens, K. Knuettel [Page 3]

Internet Draft SIP February 8, 2003

OSP Open Settlement Protocol
PKI Public Key Infrastructure
PLMN Public Line Mobile Network
PSTN Public Switched Telephone Network
URI Uniform Resource Identifier
VN Visited Network
VoIP Voice over IP

5. Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC-2119 [RFC2119].

6. Security Architecture

The proposed architecture is based on the assumption that
all entities, participating in the execution of a call,
establish a mutual Trust Domain (TD) for at least the
duration of that call. The term ‘Trust Domain’ is used in
the sense described in [RFC3324].
Such a TD can be of permanent nature or established
within the context of one or more transactions.
Based on this definition of Trust Domain the architecture
described here, can be separated into two distinct
layers:
1. Verification or Establishment of a common Trust Domain based on
existing and derived direct Trust Relationships.
2. Use the mechanisms provided by this TD – Spec(T) – to assert the
validity of VoIP calls and their related document trail.
Section 6.1 and 6.2 will outline the direct Trust Relationships
assumed in the scope of this document. Section 7 outlines how a common
Trust Domain is established. Section 8 provides example call flows that
combine the mechanisms to demonstrate how the requirements are
fulfilled.

6.1 Trust Relationships
For SIP-based VoIP to become commercially accepted,
providers need to be able to
- account and bill for their services
- be able to cooperate with other VoIP providers in routing and
signaling calls.
Both of these requirements assume trust relationships
between the user(s) being served as well as between the
operators cooperating during the call.
In order to achieve critical mass, it needs to be easy
for providers to cooperate in a flexible ad-hoc fashion
in placing and routing their calls. Authentication should
be based on a globally unique identifier, so one
principal has one AAA and billing relationship. This
unique identifier needs to specify his home domain of trust to other
entities. Within his DoT, the identifier
needs to identify his specific principal identity.
Authentication and authorization of a user can be
transparent because the user uses only one set of
credentials wherever he may be. Within this document we
assume credentials based on exchange of PKI certificates.
The model operates on direct trust relationships. A user
has an a-priori trust relationship with his home network.
Visited network and home network establish trust based on
exchange and verification of certificates.
The user and the visited network establish trust through

H. Behrens, K. Knuettel [Page 4]

Internet Draft SIP February 8, 2003

the mechanisms described in this document.
Once the user and the VN have established a trust
relationship, which is based on the VN knowing that the
HN can be charged for the credit amount authorized, the
user is fully authenticated and authorized and can use
the VN’s services.
This is even though a-priori trust or billing
relationship exists between the authenticated user and
the serving provider.

6.2 Trust Relationships between Providers and Settlement
Entity

Inter-operator accounting is still within the scope of
the architecture described here. We assume that billing
is based on a settlement and clearing entity. This entity
provides CDR-aggregation, settlement, clearing and billing
functionalities to the participating providers.
Where there is more than one such entity, we assume an
existing trust relationship between them. This
architecture assumes the existence of such an entity,
e.g. based on the Open Settlement Protocol (OSP) defined
by the ETSI [TS102.321]. It is also assumed that each
provider has its own trust relationship with the
Settlement Agency. It should be noted that the model
explicitly does not use any of the authentication or
routing functionalities proposed in that specification.
In the architecture presented here, OSP is strictly used
for aggregation of CDRs and settlement among operators.
The authors think that the fully integrated position
taken by the ETSI does not fulfil the more organic and
fluid environment of the upcoming VoIP industry.

7. Actors and Mechanisms

7.1 Actors

The actors (players) are as follows:

- The Service User (User): A user wanting to use VoIP telephony
both for inbound as well as outbound calls. A user is uniquely
identified based on his NAI, which identifies him as a user of
his home domain. A mechanism of the location of the AAA server
serving that home domain is assumed.
- The Visited Network (VN): the VN is the network a user uses when
roaming. He wants to use that networks services while being
billed by his HN. Roaming should be transparent. This means that
the user should not need an a-priori trust relationship with the
VN. It also means that he should be reachable under his home AOR
and home telephone number no matter who is roaming provider is.
- The Home Network (HN): The Home Network has two functions:
. act as a home AAA server for the User.
. act as the home VoIP network for the User.

7.2 Mechanisms

The mechanism is as follows:
- A user registers with the VN (atlanta.com in the call flow
given). The user submits his NAI in new header field ‘P-NAI’.
The user submits a bogus URI in both the From and the To header.
- The VN recognizes the registration as a P-NAI registration and
sends back a “401 Unauthorized” response, with both the From and

H. Behrens, K. Knuettel [Page 5]

Internet Draft SIP February 8, 2003

the To URI set to the temporary URI that will be assigned to the
user upon successful authentication and authorization.
- The User submits the credentials belonging to the NAI specified,
e.g. his signed public key in the next register message.
- The VN requests authentication and authorization of the user
from the home network. This can either be done through the AAA
architecture or future extensions to the SIP protocol.
- The HN authenticates the user and authorizes a certain amount of
credit. The HN includes a one-time token, which he encrypts
using the user’s public key in the return message. The HN signs
the user’s credentials and the encrypted token together with the
amount authorized. At this point authentication is established.
Authorization is still pending.
- The VN sends the user the encrypted token in a new header field
‘P-NAI-Token’ in the response to the user’s registration
request.
- The user decrypts the ‘P-NAI-Token’ with his private key. He
then encrypts it with his VN’s public key.
- The user requests a call using an INVITE message with the ‘P-
NAI-Token’ (encrypted with the VN’s certificate) inserted in the
header.
- The VN decrypts the token and encrypts it using the HN’s public
key. He uses this token in an authorization request sent to the
HN.
- The HN decrypts the received token and compares it with the
locally generated token. If they match, all necessary trust
relationships have been established.
. The HN has authenticated the user to the VN.
. The VN now trusts the user based on the VN’s trusting
the HN.
. The user trusts the VN. This is established by the VN
possessing the clear text P-NAI-Token.
. The HN receives proof of this trust and can therefore
authorize the VN to bill up to the credit amount given

8. Call Flow

Client is located in the foreign ITSP-Network and wants to be
authenticated by his home network.
Within that flow a trust relationship between the ITSPs is established.

H. Behrens, K. Knuettel [Page 6]

Internet Draft SIP February 8, 2003

|<-------------------- | |
| REGISTER F8 | |
| contains token | |
| encrypted for VN | |
|--------------------> | |
| | REGISTER F9 |
| | contains token |
| | encrypted for HN |
| |---------------------> |
| | 200 OK F10 |
| |<------------------- |
| 200 OK F11 | |
|<-------------------- | |

REGISTER sip:registrar.atlanta.com SIP/2.0
Via: SIP/2.0/UDP bobspc.atlanta.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: Alice <sip:alice@biloxi.com>
From: Alice <sip:alice@biloxi.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:alice@192.0.2.4>
Expires: 7200
P-NAI: Alice <sip:alice@biloxi.com>
Content-Length: 0

401 Unauthorized SIP/2.0
Via: SIP/2.0/UDP bobspc.atlanta.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: Alice <sip:alice_temp@atlanta.com>
From: Alice <sip:alice_temp@atlanta.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
P-NAI: Alice <sip:alice@biloxi.com>
CSeq: 1826 REGISTER
Expires: 7200
P-NAI: Alice <sip:alice@biloxi.com>
Content-Length: 0

REGISTER sip:registrar.atlanta.com SIP/2.0
Via: SIP/2.0/UDP bobspc.atlanta.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: Alice <sip:alice_temp@atlanta.com>
From: Alice <sip:alice_temp@atlanta.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1837 REGISTER
Contact: <sip:alice_temp@192.0.2.4>
Expires: 7200
P-NAI: Alice <sip:alice@biloxi.com>
Content-Length: 0
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42;
Content-Length: 568
********
*******

H. Behrens, K. Knuettel [Page 7]

Internet Draft SIP February 8, 2003

SIP/2.0 100 Trying
Via: SIP/2.0/UDP bobspc.atlanta.com:5060;branch=z9hG4bKnashds7
To: Alice <sip:alice_temp@atlanta.com>
From: Alice <sip:alice_temp@atlanta.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1837 REGISTER
Content-Length: 0

F5 /F6 TO BE DONE !

SIP/2.0 200 OK
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
;received=192.0.2.4
To: Alice <sip:alice_temp@atlanta.com>
From: Alice <sip:alice_temp@atlanta.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1837 REGISTER
Contact: <sip:alice_temp@192.0.2.4>
Expires: 7200
P-NAI-Token:
<ksjdsakjdskbdsbashbcabisedajbsdlusdbjhnsbjhdpoinwxiuermiwmpmosai
jhashbgsdgbdcuzgdbdgvdvbdbhsvsvdjhsdv>
Content-Length: 0

REGISTER sip:registrar.biloxi.com SIP/2.0
Via: SIP/2.0/UDP bobspc.atlanta.com:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: Alice <sip:alice_temp@atlanta.com>
From: Alice <sip:alice_temp@atlanta.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1847 REGISTER
Contact: <sip:alice_temp@192.0.2.4>
Expires: 7200
P-NAI: Alice <sip:alice@biloxi.com>
Content-Length: 0
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42;
Content-Length: 568
********
*******

REGISTER sip:registrar.biloxi.com SIP/2.0
Via: SIP/2.0/UDP bobspc.atlanta.com:5060;branch=z9hG4bKnashds7
Via: SIP/2.0/UDP xyv.atlanta.com:5060;branch=z9hG4bKnasdhf9
Max-Forwards: 70
To: Alice <sip:alice@biloxi.com>
From: Alice <sip:alice@biloxi.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1847 REGISTER
Contact: <sip:alice_temp@192.0.2.4>
Expires: 7200
P-NAI: Alice <sip:alice@biloxi.com>
Content-Length: 0
Content-Type: multipart/signed;

H. Behrens, K. Knuettel [Page 8]

Internet Draft SIP February 8, 2003

protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42;
Content-Length: 568
********
*******

F10

SIP/2.0 200 OK
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
;received=192.0.2.4
Via: SIP/2.0/UDP xyv.atlanta.com:5060;branch=z9hG4bKnasdhf9
To: Alice <sip:alice@biloxi.com>
From: Alice <sip:alice@biloxi.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1847 REGISTER
Contact: <sip:alice_temp@192.0.2.4>
Expires: 7200
P-NAI-Token:
<ksjdsakjdskbdsbashbcabisedajbsdlusdbjhnsbjhdpoinwxiuermiwmpmosa
ijhashbgsdgbdcuzgdbdgvdvbdbhsvsvdjhsdv>
Content-Length: 0

F11

SIP/2.0 200 OK
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
;received=192.0.2.4
To: Alice <sip:alice@biloxi.com>
From: Alice <sip:alice@biloxi.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1847 REGISTER
Contact: <sip:alice_temp@192.0.2.4>
Expires: 7200
P-NAI-Token:
<ksjdsakjdskbdsbashbcabisedajbsdlusdbjhnsbjhdpoinwxiuermiwmpmosa
ijhashbgsdgbdcuzgdbdgvdvbdbhsvsvdjhsdv>
Content-Length: 0

IANA Considerations

SIP headers defined: P-NAI, P-NAI-Token

Normative description: This document

9. Authors' Addresses

Dr. Harry Behrens
snom technology AG
Pascalstr. 10B
10587 Berlin
Germany
Email: hb@snom.com

Karsten Knuettel
Fraunhofer FOKUS
Kaiserin-Augusta-Allee 31
10589 Berlin

H. Behrens, K. Knuettel [Page 9]

Internet Draft SIP February 8, 2003

Email: knuettel@fokus.fraunhofer.de

10. Bibliography

[CARON.1]Caron, J., “Public Wireless LAN roaming issues”,
<draft-caron-public-wlan-roaming-issues-00.txt>,
WIP,
February 2002.
[CARON.2]Caron, J., “DNS-based Roaming”,
<draft-caron-dns-based-roaming-00.txt>, WIP,
April 2002.
[PETERSON.1] Peterson, J. “Enhancements for
Authenticated Identity
Management in the Session Initiation Protocol
(SIP)”,
<draft-ietf-sip-identity-01>, WIP, February
2003.
[RFC2194] Aboba, B. et al., "Review of Roaming
Implementations", RFC2194, September 1997
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", RFC2119, March
1997
[RFC2486]Aboba, B. et al., "The Network Access
Identifier",
January 1999
[RFC3261]Rosenberg, J., Schulzrinne H., Camarillo G.,
Johnston, A.R., Peterson, J., Sparks, R.,
Handley, M. and E. Schooler, "SIP: Session
Initiation Protocol", RFC 3261, Internet
Engineering Task Force, June 2002.
[RFC3325] Jennings, C. et al. "Private Extensions to the
Session Initiation Protocol (SIP) for Asserted
Identity within Trusted Networks", November
2002
[TS102.321] ETSI TS, “Telecommunications and Internet
Protocol Harmonization Over Networks (TIPHON);
Open Settlement Protocol (OSP) for Interdomain
Pricing, authorization and usage exchange”,
Technical Specification 101 321.
[RFC3261] . Rosenberg, H. Schulzrinne, G. Camarillo, A.
R. Johnston, J.Peterson, R. Sparks, M. Handley,
and E. Schooler, "SIP: Session Initiation
Protocol", RFC 3261, Internet Engineering Task
Force, June 2002.

The IETF takes no position regarding the validity or
scope of any intellectual property 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; neither does it represent that it
has made any effort to identify any such rights.
Information on the IETF's procedures with respect to
rights in standards-track and standards-related
documentation can be found in BCP-11. Copies of claims
of rights made available for publication 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
implementors or users of this specification can be
obtained from the IETF Secretariat.

H. Behrens, K. Knuettel [Page 10]

Internet Draft SIP February 8, 2003

The IETF invites any interested party to bring to its
attention any copyrights, patents or patent
applications, or other proprietary rights which may
cover technology that may be required to practice this
standard. Please address the information to the IETF
Executive Director.

Full Copyright Statement

This document and translations of it may be copied and
furnished to others, and derivative works that comment
on or otherwise explain it or assist in its
implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of
any kind, provided that the above copyright notice and
this paragraph are included on all such copies and
derivative works. However, this document itself may not
be modified in any way, such as by removing the
copyright notice or references to the Internet Society or
other Internet organizations, except as needed for the
purpose of developing Internet standards in which case
the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to
translate it into languages other than English.

The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its
successors or assigns.

This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

H. Behrens, K. Knuettel [Page 11]