Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format
RFC 3893

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

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 the