Summary

  • RFC 3324 separated administrative membership from operational trust: B trusted A only when B had a secure connection to A and configuration saying A belonged to the domain.
  • An asserted identity arriving from a node the receiver did not trust carried no authenticity or integrity guarantee and had to be excluded from display, forwarding and service decisions.

The domain was not a blanket credential

The phrase “trust domain” invites the wrong mental picture: a perimeter inside which every participant may believe every other participant. RFC 3324 refused that shortcut. A node belonged to domain T when it was known to comply with the agreed specification and configuration set called Spec(T). Human operators constructed that membership. One operator could know its own equipment; several operators could join domains through bilateral agreements. None of that automatically gave every node a secure, configured relationship with every other node.

The document defined a narrower statement. B trusted A only if two conditions were true at B: the nodes had a secure connection, and B had configuration identifying A as a member of the domain. The direction matters. B could trust A while A did not trust B. A receiver could trust an immediate network intermediary even while remaining outside the domain itself. The RFC's diagram then made the point impossible to dismiss: A, B and C were all inside one trust domain, yet A trusted C and did not trust B.

That distinction turned trust into a locally verifiable edge. Membership was a property of the compatibility set. Acceptance was a decision available to a particular receiver about a particular peer. The receiver did not possess an oracle containing the complete trust state of every node in the domain. For that reason RFC 3324 rejected sentences such as “when a node receives information from a trusted node.” It permitted the more exact formulation: information received from another node that it trusts.

The assertion inherited the edge

Network Asserted Identity began with an authentication process performed by a SIP network intermediary. The resulting identity could be a SIP, secure SIP or telephone URI meaningful inside the responsible domain or number range. The authentication method and at least its reliability were part of Spec(T). A user could offer a preferred identity, but domain policy controlled whether that preference informed the asserted value.

The ordinary From field did not provide the same evidence. SIP allowed a user to present a desired alias. A relying user agent might lack the key material needed to authenticate another user agent directly. The short-term network mechanism therefore let an intermediary derive an identity and send it through securely connected nodes that understood the same rules.

Yet the assertion did not float free of its path. Its value at a receiver depended on the immediate sender being a node that receiver trusted. If the identity arrived from a node it did not trust, RFC 3324 said it carried no guarantee of authenticity or integrity because the receiver could not know that Spec(T) had governed generation and transport. The consequence was unusually concrete: the information must not be displayed, passed onward or used as service input.

This was not a claim that the secure channel proved every upstream fact. The channel protected against reading and undetected modification by third parties and allowed B to identify A as the sender. Correct receiver configuration connected A to the agreed domain. Confidence in the original authentication still depended on Spec(T), the deriving intermediary and the procedures actually followed. Each receipt answered a different question.

A compatibility set, not Internet-wide identity

RFC 3324 repeatedly limited its ambition. The requirements addressed exchange inside a community of devices known to follow common rules, plus a secure direct connection from such a node to an outside receiver that trusted it. General transport of network-asserted identity across arbitrary Internet hosts was out of scope. The security section warned that other uses had serious shortcomings: the recipient had no guarantee that the information had remained unchanged or had been correct in the first place.

Spec(T) was also subtler than a standards citation. It need not be one written document. It was the agreed information that participants used to understand what was asserted, how it was determined, how strong authentication was, how integrity was protected and what privacy policy applied. A header name without that operational agreement was incomplete evidence.

Privacy further constrained the edge. A message could indicate that asserted identity must not be passed to other users. A separate indication could record the user's own request, because domain policy might distinguish user intent from another legal or operational reason. Identity could continue inside the trusted network while being withheld from an outside user. That was compatible with the observer-relative privacy model of RFC 3323, but it was not the same mechanism or claim.

RFC 3325 later supplied private SIP extensions for asserted identity, while RFC 5876 updated that mechanism. RFCs 4474, 8224 and 8225 developed different approaches to authenticated identity and PASSporT. Their existence does not retroactively turn RFC 3324 into universal proof. RFC 3324 remains valuable because it exposed the hidden precondition beneath a network assertion: a receiver must name the peer, verify the channel, know the membership configuration and understand the rule set that produced the claim.

The historical lesson is precise. A domain boundary could organize compatible behavior, but it could not perform verification on behalf of every participant. Trust was not ambient. It arrived, if at all, on a directed edge that the receiver could explain.

Sources