Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format
RFC 3893
Document | Type | RFC - Proposed Standard (September 2004; No errata) | |
---|---|---|---|
Author | Jon Peterson | ||
Last updated | 2015-10-14 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3893 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Allison Mankin | ||
Send notices to | <rohan@cisco.com> |
Network Working Group J. Peterson Request for Comments: 3893 NeuStar Category: Standards Track September 2004 Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). Abstract RFC 3261 introduces the concept of adding an S/MIME body to a Session Initiation Protocol (SIP) request or response in order to provide reference integrity over its headers. This document provides a more specific mechanism to derive integrity and authentication properties from an 'authenticated identity body', a digitally-signed SIP message, or message fragment. A standard format for such bodies (known as Authenticated Identity Bodies, or AIBs) is given in this document. Some considerations for the processing of AIBs by recipients of SIP messages with such bodies are also given. Peterson Standards Track [Page 1] RFC 3893 SIP Authenticated Identity Body (AIB) FormatSeptember 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Notation. . . . . . . . . . . . . . . . . . 3 2. AIB Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Example of a Request with AIB . . . . . . . . . . . . . . . . 5 4. AIBs for Identifying Third-Parties . . . . . . . . . . . . . . 6 5. Identity in non-INVITE Requests . . . . . . . . . . . . . . . 7 6. Identity in Responses . . . . . . . . . . . . . . . . . . . . 7 7. Receiving an AIB . . . . . . . . . . . . . . . . . . . . . . . 7 8. Encryption of Identity . . . . . . . . . . . . . . . . . . . . 8 9. Example of Encryption . . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . 11 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 14. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 15. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13 1. Introduction Section 23.4 of RFC 3261 [1] describes an integrity mechanism that relies on signing tunneled 'message/sip' MIME bodies within SIP requests. The purpose of this mechanism is to replicate the headers of a SIP request within a body carried in that request in order to provide a digital signature over these headers. The signature on this body also provides authentication. The core requirement that motivates the tunneled 'message/sip' mechanism is the problem of providing a cryptographically verifiable identity within a SIP request. The baseline SIP protocol allows a user agent to express the identity of its user in any of a number of headers. The primary place for identity information asserted by the sender of a request is the From header. The From header field contains a URI (like 'sip:alice@example.com') and an optional display-name (like "Alice") that identifies the originator of the request. A user may have many identities that are used in different contexts. Typically, this URI is an address-of-record that can be de-referenced in order to contact the originator of the request; specifically, it is usually the same address-of-record under which a user registers their devices in order to receive incoming requests. This address- of-record is assigned and maintained by the administrator of the SIP service in the domain identified by the host portion of the address- of-record. However, the From field of a request can usually be set Peterson Standards Track [Page 2] RFC 3893 SIP Authenticated Identity Body (AIB) FormatSeptember 2004 arbitrarily by the user of a SIP user agent; the From header of a message provides no internal assurance that the originating user can legitimately claim the given identity. Nevertheless, many SIP user agents will obligingly display the contents of the From field as the identity of the originator of a received request (as a sort of caller identification function), much as email implementations display theShow full document text