|----INVITE----->| | |
| |---Is this OK?-->| |
| | | |
| |<------OK--------| |
| | | |
| |---------INVITE------------------>|
| | | |
| |-Accounting msg->| |
| | | |
Figure 2: WLAN roaming user
User A accesses the Internet using a WLAN access outside his home
domain. User A, user B, SIP proxy C, and the home AAA server of user
A are all in different domains.
SIP proxy C challenges the initial INVITE from user A with a 407
(Proxy Authentication Required) response, and user A reissues the
INVITE including his credentials. SIP proxy C consults user A’s home
AAA server, which confirms that the credentials belong to user A and
that SIP proxy C can go ahead and provide its service for that call.
SIP proxy C routes the INVITE forward towards user B and sends an
accounting message to the AAA server, which will be used later to
charge user A for the service provided by SIP proxy C.
3.2. Conditional Authorization
User A is not in his home domain, but he still uses SIP proxy C
(which is in user’s A home domain) as the outbound proxy for an
INVITE. SIP proxy C consults the home AAA server, which indicates
that requests from user A have to be routed through SIP proxy D. SIP
proxy C uses SIP loose routing so that the INVITE traverses D before
reaching its destination. SIP proxy D will provide a call log
service for user A.
SIP AAA SIP
User A Proxy C Server Proxy D
| | | |
|----INVITE----->| | |
| | | |
|<-----407-------| | |
| | | |
|------ACK------>| | |
| | | |
|----INVITE----->| | |
| |------Is this OK?---->| |
| | | |
| |<-OK if routed thru D-| |
| | | |
| |---------INVITE------------------>|
| | | |
Figure 3: Conditional Authorization
4. Security Considerations
Security is a critical requirement of the SIP-AAA Interface. Section
2.1.9 describes the threats and security requirements. Sections 2.2
and 2.3 elaborate on the authentication and authorization
requirements.
5. Acknowledgements
The authors would like to thank the participants of the SIP interim
meeting, May 2002 for their comments. The authors would also thank
Harri Hakala, Mary Barns, Pete McCann, Jari Arkko, Aki Niemi, Juha
Heinanen, Henry Sinnreich, Allison Mankin, and Bernard Aboba for
their comments.
The authors would like to thank the authors of the "AAA Requirements
for IP Telephony/Multimedia" document, as it provided a basis for
some of the information contained in this document.
6. References
6.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Bradner, S., "Key words for use in RFCs to indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[4] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP
Authentication, Authorization, and Accounting Requirements", RFC
2977, October 2000.
[5] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial in User Service (RADIUS)", RFC 2865, June
2000.
[6] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
[7] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba,
"Dynamic Authorization Extensions to Remote Authentication Dial
in User Service (RADIUS)", RFC 3576, July 2003.
[8] Aboba, B., Arkko, J. and D. Harrington, "Introduction to
Accounting Management", RFC 2975, October 2000.
7. Authors’ Addresses
John Loughney
Nokia
Itamerenkatu 11-13
00180 Helsinki
Finland
EMail: John.Loughney@nokia.com
Gonzalo Camarillo
Ericsson
Advanced Signalling Research Lab.
FIN-02420 Jorvas
Finland
EMail: Gonzalo.Camarillo@ericsson.com
8. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.