Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format
Extracted elements (22)
A signature over only the From header is insufficient because it is susceptible to cut-and-paste replay attacks; additional headers (Date, Call-ID, Contact) are needed to correlate the signature with a specific request instance.
RFC 3261's tunneled 'message/sip' approach signs all headers, but many headers change in transit for legitimate reasons, forcing recipients to distinguish valid from invalid changes. AIBs sign only the identity-critical subset via 'message/sipfrag', reducing the verification burden and false positives.
The To and CSeq fields are RECOMMENDED but not required in AIBs because their utility is context-dependent: CSeq provides per-transaction replay protection only if a new AIB is issued per transaction, and To may be inappropriate in third-party call scenarios where retargeting is involved.
AIBs are proposed as a replacement for RFC 3261 Section 23.4 tunneled 'message/sip' for identity purposes; the 'message/sip' mechanism should still be used when integrity over other unrelated headers is required.
For third-party scenarios such as REFER and 3PCC, Call-ID and CSeq from the original request do not correspond to those in the subsequent INVITE, making it difficult to correlate a supplemental AIB; further specification work is required to define which headers to include and how to differentiate primary from third-party AIBs.
AIBs using 'message/sipfrag' MUST contain the From, Date, Call-ID, and Contact headers when providing identity for an INVITE request; they SHOULD also contain the To and CSeq headers.
An AIB MIME body MUST have a Content-Disposition disposition-type of 'aib'. The Content-Disposition header SHOULD also contain a 'handling' parameter set to optional.
Analysis of Date, Call-ID, and Contact header fields for reference integrity MUST also be performed when receiving an AIB; any discrepancies or violations MUST be reported to the user.
For non-INVITE requests within a dialog, the From, Call-ID, Date, and Contact header fields are REQUIRED in an AIB. New SIP methods or extensions leveraging AIB security MUST identify any special identity requirements in their Security Considerations.
Implementations MUST follow RFC 3261 Section 23.4.2 rules for acceptance of the Date header field: the Date must indicate a time within 3600 seconds of message receipt, preventing replay of outdated AIBs.
Implementations MUST record Call-IDs received in AIBs and MUST remember them for at least 3600 seconds (one Date interval) to detect replayed AIBs via Call-ID duplication.
In an AIB for a response to an INVITE, the From header MUST correspond to the address-of-record of the responder (not the From of the request), and the To header field of the request MUST NOT be included.
Unsigned AIBs MUST be treated by recipients according to the rules for AIBs that do not validate (Section 7). After signing, the AIB SHOULD be added to existing MIME bodies, transitioning to 'multipart/mixed' if necessary.
When a user agent receives a request with an AIB, it MUST verify the signature and certificate of the signer, compare the signer's subjectAltName with the domain portion of the From header URI, and MUST report any discrepancy to the user before proceeding.
When an AIB is encrypted, it SHOULD be encrypted before it is signed. Implementations MUST still accept AIBs that have been signed and then encrypted.
When an originating UA receives a response with an AIB, it SHOULD compare the From header in the AIB with the original To header of the request, and SHOULD render the AIB identity to the user if they differ.
The Authenticated Identity Body (AIB) is a MIME body of type 'message/sipfrag' with Content-Disposition disposition-type 'aib', digitally signed to provide cryptographic identity for the sender of a SIP message. It carries a subset of SIP headers sufficient to assert and verify the originator's identity.
This document defines a new MIME Content-Disposition disposition-type value of 'aib', reserved for MIME bodies containing an authenticated identity as described in Section 2.
Encryption of AIBs relies on secure distribution of a shared decryption key; the security of the AIB is therefore predicated on key distribution integrity, and widespread key sharing may only be appropriate in federated trust environments such as telephone networks.
The Contact, Date, Call-ID, and From headers are mandated in AIBs to resist replay and cut-and-paste attacks. The Date header enforces a 3600-second freshness window; the Call-ID cache prevents replays within that window; and Contact ties the AIB to a specific device so an attacker cannot reuse a stolen AIB to receive calls.
The subjectAltName in the signer's certificate must match the domain portion of the From header URI; if not, the UA must report the discrepancy to the user, as this indicates a potential identity mismatch or impersonation attempt.
An AIB is encoded as a 'message/sipfrag' MIME body (per RFC 3420) with Content-Disposition set to 'aib; handling=optional', signed using S/MIME (multipart/signed with application/pkcs7-signature). The signed body is embedded in a multipart/mixed alongside other MIME bodies such as SDP.