doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc3893.txt b/doc/rfc/rfc3893.txt
new file mode 100644
index 0000000..47b16c2
--- /dev/null
+++ b/doc/rfc/rfc3893.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+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
+   From field as the sender's identity.
+
+   In order to provide the recipient of a SIP message with greater
+   assurance of the identity of the sender, a cryptographic signature
+   can be provided over the headers of the SIP request, which allows the
+   signer to assert a verifiable identity.  Unfortunately, a signature
+   over the From header alone is insufficient because it could be cut-
+   and-pasted into a replay or forwarding attack, and more headers are
+   therefore needed to correlate a signature with a request.  RFC 3261
+   therefore recommends copying all of the headers from the request into
+   a signed MIME body; however, SIP messages can be large, and many of
+   the headers in a SIP message would not be relevant in determining the
+   identity of the sender or assuring reference integrity with the
+   request, and moreover some headers may change in transit for
+   perfectly valid reasons.  Thus, this large tunneled 'message/sip'
+   body will almost necessarily be at variance with the headers in a
+   request when it is received by the UAS, and the burden in on the UAS
+   to determine which header changes were legitimate, and which were
+   security violations.  It is therefore desirable to find a happy
+   medium - to provide a way of signing just enough headers that the
+   identity of the sender can be ascertained and correlated with the
+   request.  'message/sipfrag' [4] provides a way for a subset of SIP
+   headers to be included in a MIME body; the Authenticated Identity
+   Body (AIB) format described in Section 2 is based on
+   'message/sipfrag'.
+
+   For reasons of end-to-end privacy, it may also be desirable to
+   encrypt AIBs; procedures for this encryption are given in Section 8.
+
+   This document proposes that the AIB format should be used instead of
+   the existing tunneled 'message/sip' mechanism described in RFC 3261,
+   section 23.4, in order to provide the identity of the caller; if
+   integrity over other, unrelated headers is required, then the
+   'message/sip' mechanism should be used.
+
+1.1.  Requirements Notation
+
+   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 BCP 14, RFC 2119 [2].
+
+
+
+
+
+Peterson                    Standards Track                     [Page 3]
+
+RFC 3893      SIP Authenticated Identity Body (AIB) FormatSeptember 2004
+
+
+2.  AIB Format
+
+   As a way of sharing authenticated identity among parties in the
+   network, a special type of MIME body format, the Authenticated
+   Identity Body (AIB) format, is defined in this section.  AIBs allow a
+   party in a SIP transaction to cryptographically sign the headers that
+   assert the identity of the originator of a message, and provide some
+   other headers necessary for reference integrity.
+
+   An AIB is a MIME body of type 'message/sipfrag' - for more
+   information on constructing sipfrags, including examples, see [4].
+   This MIME body MUST have a Content-Disposition [3] disposition-type
+   of 'aib', a new value defined in this document specifically for
+   authenticated identity bodies.  The Content-Disposition header SHOULD
+   also contain a 'handling' parameter indicating that this MIME body is
+   optional (i.e., if this mechanism is not supported by the user agent
+   server, it can still attempt to process the request).
+
+   AIBs using the 'message/sipfrag' MIME type MUST contain the following
+   headers when providing identity for an INVITE request: From, Date,
+   Call-ID, and Contact; they SHOULD also contain the To and CSeq
+   header.  The security properties of these headers, and circumstances
+   in which they should be used, are described in Section 10.  AIBs MAY
+   contain any other headers that help to uniquely identify the
+   transaction or provide related reference integrity.  An example of
+   the AIB format for an INVITE is:
+
+   Content-Type: message/sipfrag
+   Content-Disposition: aib; handling=optional
+
+   From: Alice <sip:alice@example.com>
+   To: Bob <sip:bob@example.net>
+   Contact: <sip:alice@pc33.example.com>
+   Date: Thu, 21 Feb 2002 13:02:03 GMT
+   Call-ID: a84b4c76e66710
+   CSeq: 314159 INVITE
+
+   Unsigned AIBs MUST be treated by any recipients according to the
+   rules set out in Section 7 for AIBs that do not validate.  After the
+   AIB has been signed, it SHOULD be added to existing MIME bodies in
+   the request (such as SDP), if necessary by transitioning the
+   outermost MIME body to a 'multipart/mixed' format.
+
+
+
+
+
+
+
+
+
+Peterson                    Standards Track                     [Page 4]
+
+RFC 3893      SIP Authenticated Identity Body (AIB) FormatSeptember 2004
+
+
+3.  Example of a Request with AIB
+
+   The following shows a full SIP INVITE request with an AIB:
+
+   INVITE sip:bob@example.net SIP/2.0
+   Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
+   To: Bob <sip:bob@example.net>
+   From: Alice <sip:alice@example.com>;tag=1928301774
+   Call-ID: a84b4c76e66710
+   CSeq: 314159 INVITE
+   Max-Forwards: 70
+   Date: Thu, 21 Feb 2002 13:02:03 GMT
+   Contact: <sip:alice@pc33.example.com>
+   Content-Type: multipart/mixed; boundary=unique-boundary-1
+
+   --unique-boundary-1
+
+   Content-Type: application/sdp
+   Content-Length: 147
+
+   v=0
+   o=UserA 2890844526 2890844526 IN IP4 example.com
+   s=Session SDP
+   c=IN IP4 pc33.example.com
+   t=0 0
+   m=audio 49172 RTP/AVP 0
+   a=rtpmap:0 PCMU/8000
+
+   --unique-boundary-1
+   Content-Type: multipart/signed;
+     protocol="application/pkcs7-signature";
+     micalg=sha1; boundary=boundary42
+   Content-Length: 608
+
+   --boundary42
+   Content-Type: message/sipfrag
+   Content-Disposition: aib; handling=optional
+
+   From: Alice <sip:alice@example.com>
+   To: Bob <sip:bob@example.net>
+   Contact: <sip:alice@pc33.example.com>
+   Date: Thu, 21 Feb 2002 13:02:03 GMT
+   Call-ID: a84b4c76e66710
+   CSeq: 314159 INVITE
+
+   --boundary42
+   Content-Type: application/pkcs7-signature; name=smime.p7s
+   Content-Transfer-Encoding: base64
+
+
+
+Peterson                    Standards Track                     [Page 5]
+
+RFC 3893      SIP Authenticated Identity Body (AIB) FormatSeptember 2004
+
+
+   Content-Disposition: attachment; filename=smime.p7s;
+      handling=required
+
+   ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
+   4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
+   n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
+   7GhIGfHfYT64VQbnj756
+
+   --boundary42--
+
+   --unique-boundary-1--
+
+4.  AIBs for Identifying Third-Parties
+
+   There are special-case uses of the INVITE method in which some SIP
+   messages are exchanged with a third party before an INVITE is sent,
+   and in which the identity of the third party needs to be carried in
+   the subsequent INVITE.  The details of addressing identity in such
+   contexts are outside the scope of this document.  At a high level, it
+   is possible that identity information for a third party might be
+   carried in a supplemental AIB.  The presence of a supplemental AIB
+   within a message would not preclude the appearance of a 'regular' AIB
+   as specified in this document.
+
+   Example cases in which supplemental AIBs might appear include:
+
+      The use of the REFER [5] method, for example, has a requirement
+      for the recipient of an INVITE to ascertain the identity of the
+      referrer who caused the INVITE to be sent.
+
+      Third-party call control (3PCC [6]) has an even more complicated
+      identity problem.  A central controller INVITEs one party, gathers
+      identity information (and session context) from that party, and
+      then uses this information to INVITE another party.  Ideally, the
+      controller would also have a way to share a cryptographic identity
+      signature given by the first party INVITEd by the controller to
+      the second party invited by the controller.
+
+   In both of these cases, the Call-ID and CSeq of the original request
+   (3PCC INVITE or REFER) would not correspond with that of the request
+   in by the subsequent INVITE, nor would the To or From.  In both the
+   REFER case and the 3PCC case, the Call-ID and CSeq cannot be used to
+   guarantee reference integrity, and it is therefore much harder to
+   correlate an AIB to a subsequent INVITE request.
+
+   Thus, in these cases some other headers might be used to provide
+   reference integrity between the headers in a supplemental AIB with
+   the headers of a 3PCC or REFER-generated INVITE, but this usage is
+
+
+
+Peterson                    Standards Track                     [Page 6]
+
+RFC 3893      SIP Authenticated Identity Body (AIB) FormatSeptember 2004
+
+
+   outside of the scope of this document.  In order for AIBs to be used
+   in these third-party contexts, further specification work is required
+   to determine which additional headers, if any, need to be included in
+   an AIB in a specific third-party case, and how to differentiate the
+   primary AIB in a message from a third-party AIB.
+
+5.  Identity in non-INVITE Requests
+
+   The requirements for populating an AIB in requests within a dialog
+   generally parallel those of the INVITE: From, Call-ID, Date, and
+   Contact header fields are REQUIRED.
+
+   Some non-INVITE requests, however, may have different identity
+   requirements.  New SIP methods or extensions that leverage AIB
+   security MUST identify any special identity requirements in the
+   Security Considerations of their specification.
+
+6.  Identity in Responses
+
+   Many of the practices described in the preceding sections can be
+   applied to responses as well as requests.  Note that a new set of
+   headers must be generated to populate the AIB in a response.  The
+   From header field of the AIB in the response to an INVITE MUST
+   correspond to the address-of-record of the responder, NOT to the From
+   header field received in the request.  The To header field of the
+   request MUST NOT be included.  A new Date header field and Contact
+   header field should be generated for the AIB in a response.  The
+   Call-ID and CSeq should, however, be copied from the request.
+
+   Generally, the To header field of the request will correspond to the
+   address-of-record of the responder.  In some architectures where re-
+   targeting is used, however, this need not be the case.  Some
+   recipients of response AIBs may consider it a cause for security
+   concern if the To header field of the request is not the same as the
+   address-of-record in the From header field of the AIB in a response.
+
+7.  Receiving an AIB
+
+   When a user agent receives a request containing an AIB, it MUST
+   verify the signature, including validating the certificate of the
+   signer, and compare the identity of the signer (the subjectAltName)
+   with, in the INVITE case, the domain portion of the URI in the From
+   header field of the request (for non-INVITE requests, other headers
+   MAY be subject to this comparison).  The two should correspond
+   exactly; if they do not, the user agent MUST report this condition to
+   its user before proceeding.  User agents MAY distinguish between
+   plausibly minor variations (the difference between 'example.com' and
+   'sip.example.com') and major variations ('example.com' vs.
+
+
+
+Peterson                    Standards Track                     [Page 7]
+
+RFC 3893      SIP Authenticated Identity Body (AIB) FormatSeptember 2004
+
+
+   'example.org') when reporting these discrepancies in order to give
+   the user some idea of how to handle this situation.  Analysis and
+   comparison of the Date, Call-ID, and Contact header fields as
+   described in Section 10 MUST also be performed.  Any discrepancies or
+   violations MUST be reported to the user.
+
+   When the originating user agent of a request receives a response
+   containing an AIB, it SHOULD compare the identity in the From header
+   field of the AIB of the response with the original value of the To
+   header field in the request.  If these represent different
+   identities, the user agent SHOULD render the identity in the AIB of
+   the response to its user.  Note that a discrepancy in these identity
+   fields is not necessarily an indication of a security breach; normal
+   re-targeting may simply have directed the request to a different
+   final destination.  Implementors therefore may consider it
+   unnecessary to alert the user of a security violation in this case.
+
+8.  Encryption of Identity
+
+   Many SIP entities that support the use of S/MIME for signatures also
+   support S/MIME encryption, as described in RFC 3261, Section 23.4.3.
+
+   While encryption of AIBs entails that only the holder of a specific
+   key can decrypt the body, that single key could be distributed
+   throughout a network of hosts that exist under common policies.  The
+   security of the AIB is therefore predicated on the secure
+   distribution of the key.  However, for some networks (in which there
+   are federations of trusted hosts under a common policy), the
+   widespread distribution of a decryption key could be appropriate.
+   Some telephone networks, for example, might require this model.
+
+   When an AIB is encrypted, the AIB SHOULD be encrypted before it is
+   signed.  Implementations MUST still accept AIBs that have been signed
+   and then encrypted.
+
+9.  Example of Encryption
+
+   The following is an example of an encrypted and signed AIB (without
+   any of the preceding SIP headers).  In a rendition of this body sent
+   over the wire, the text wrapped in asterisks would be in ciphertext.
+
+   Content-Type: multipart/signed;
+     protocol="application/pkcs7-signature";
+     micalg=sha1; boundary=boundary42
+   Content-Length: 568
+   Content-Disposition: aib; handling=optional
+
+   --boundary42
+
+
+
+Peterson                    Standards Track                     [Page 8]
+
+RFC 3893      SIP Authenticated Identity Body (AIB) FormatSeptember 2004
+
+
+   Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
+     name=smime.p7m
+   Content-Transfer-Encoding: base64
+   Content-Disposition: attachment; filename=smime.p7m
+     handling=required
+   Content-Length: 231
+
+   ***********************************************************
+   * Content-Type: message/sipfrag                           *
+   * Content-Disposition: aib; handling=optional             *
+   *                                                         *
+   * From: sip:alice@example.com                             *
+   * Call-ID: a84b4c76e66710                                 *
+   * Contact: sip:alice@device21.example.com                 *
+   * Date: Thu, 21 Feb 2002 13:02:03 GMT                     *
+   ***********************************************************
+
+   --boundary42
+
+   Content-Type: application/pkcs7-signature; name=smime.p7s
+   Content-Transfer-Encoding: base64
+   Content-Disposition: attachment; filename=smime.p7s;
+      handling=required
+
+   ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
+   4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
+   n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
+   7GhIGfHfYT64VQbnj756
+
+   --boundary42--
+
+10.  Security Considerations
+
+   The purpose of an AIB is to provide an identity for the sender of a
+   SIP message.  This identity is held in the From header field of an
+   AIB.  While other headers are also included, they are provided solely
+   to assist in detection of replays and cut-and-paste attacks leveraged
+   to impersonate the caller.  The contents of the From header field of
+   a valid AIB are suitable for display as a "Caller ID" for the sender
+   of the SIP message.
+
+   This document mandates the inclusion of the Contact, Date, Call-ID,
+   and From header fields within an AIB, and recommends the inclusion of
+   CSeq and To header fields, when 'message/sipfrag' is used to
+   represent the identity of a request's sender.  If these headers are
+   omitted, some important security properties of AIB are lost.  In
+   general, the considerations related to the inclusion of various
+   headers in an AIB are the same as those given in RFC 3261 for
+
+
+
+Peterson                    Standards Track                     [Page 9]
+
+RFC 3893      SIP Authenticated Identity Body (AIB) FormatSeptember 2004
+
+
+   including headers in tunneled 'message/sip' MIME bodies (see Section
+   23 in particular).
+
+   The From header field indicates the identity of the sender of the
+   message; were this header to be excluded, the creator of the AIB
+   essentially would not be asserting an identity at all.  The Date and
+   Contact headers provide reference integrity and replay protection, as
+   described in RFC 3261, Section 23.4.2.  Implementations of this
+   specification MUST follow the rules for acceptance of the Date header
+   field in tunneled 'message/sip' requests described in RFC 3261,
+   Section 23.4.2; this ensures that outdated AIBs will not be replayed
+   (the suggested interval is that the Date header must indicate a time
+   within 3600 seconds of the receipt of a message).  Implementations
+   MUST also record Call-IDs received in AIBs, and MUST remember those
+   Call-IDs for at least the duration of a single Date interval (i.e.,
+   3600 seconds).  Accordingly, if an AIB is replayed within the Date
+   interval, receivers will recognize that it is invalid because of a
+   Call-ID duplication; if an AIB is replayed after the Date interval,
+   receivers will recognize that it is invalid because the Date is
+   stale.  The Contact header field is included to tie the AIB to a
+   particular device instance that generated the request.  Were an
+   active attacker to intercept a request containing an AIB, and cut-
+   and-paste the AIB into their own request (reusing the From, Contact,
+   Date, and Call-ID fields that appear in the AIB), they would not be
+   eligible to receive SIP requests from the called user agent, since
+   those requests are routed to the URI identified in the Contact header
+   field.
+
+   The To and CSeq header fields provide properties that are generally
+   useful, but not for all possible applications of AIBs.  If a new AIB
+   is issued each time a new SIP transaction is initiated in a dialog,
+   the CSeq header field provides a valuable property (replay protection
+   for this particular transaction).  If, however, one AIB is used for
+   an entire dialog, subsequent transactions in the dialog would use the
+   same AIB that appeared in the INVITE transaction.  Using a single AIB
+   for an entire dialog reduces the load on the generator of the AIB.
+   The To header field usually designates the original URI that the
+   caller intended to reach, and therefore it may vary from the
+   Request-URI if re-targeting occurs at some point in the network.
+   Accordingly, including the To header field in the AIB helps to
+   identify cut-and-paste attacks in which an AIB sent to a particular
+   destination is re-used to impersonate the sender to a different
+   destination.  However, the inclusion of the To header field probably
+   would not make sense for many third-party AIB cases (as described in
+   Section 4), nor is its inclusion necessary for responses.
+
+
+
+
+
+
+Peterson                    Standards Track                    [Page 10]
+
+RFC 3893      SIP Authenticated Identity Body (AIB) FormatSeptember 2004
+
+
+11.  IANA Considerations
+
+   This document defines a new MIME Content-Disposition disposition-type
+   value of 'aib'.  This value is reserved for MIME bodies that contain
+   an authenticated identity, as described in section Section 2.
+
+12.  References
+
+12.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.
+
+        [3]  Troost, R., Dorner, S., and K. Moore, "Communicating
+        Presentation Information in Internet Messages: The Content-
+        Disposition Header Field", RFC 2183, August 1997.
+
+   [4]  Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
+        November 2002.
+
+12.2.  Informative References
+
+   [5]  Sparks, R., "The Session Initiation Protocol (SIP) Referred-By
+        Mechanism", RFC 3892, September 2004.
+
+   [6]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
+        "Best Current Practices for Third Party Call Control (3pcc) in
+        the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April
+        2004.
+
+13.  Acknowledgements
+
+   The author would like to thank Robert Sparks, Jonathan Rosenberg,
+   Mary Watson, and Eric Rescorla for their comments.  Rohan Mahy also
+   provided some valuable guidance.
+
+
+
+
+
+
+
+
+
+
+
+
+Peterson                    Standards Track                    [Page 11]
+
+RFC 3893      SIP Authenticated Identity Body (AIB) FormatSeptember 2004
+
+
+14.  Author's Address
+
+   Jon Peterson
+   NeuStar, Inc.
+   1800 Sutter St
+   Suite 570
+   Concord, CA  94520
+   US
+
+   Phone: +1 925/363-8720
+   EMail: jon.peterson@neustar.biz
+   URI:   http://www.neustar.biz/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Peterson                    Standards Track                    [Page 12]
+
+RFC 3893      SIP Authenticated Identity Body (AIB) FormatSeptember 2004
+
+
+15.  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/S HE
+   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 IETF's procedures with respect to rights in IETF 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.
+
+
+
+
+
+
+
+Peterson                    Standards Track                    [Page 13]
+