1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011
|
Network Working Group C. Jennings
Request for Comments: 3325 Cisco Systems
Category: Informational J. Peterson
NeuStar, Inc.
M. Watson
Nortel Networks
November 2002
Private Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document describes private extensions to the Session Initiation
Protocol (SIP) that enable a network of trusted SIP servers to assert
the identity of authenticated users, and the application of existing
privacy mechanisms to the identity problem. The use of these
extensions is only applicable inside an administrative domain with
previously agreed-upon policies for generation, transport and usage
of such information. This document does NOT offer a general privacy
or identity model suitable for use between different trust domains,
or use in the Internet at large.
Table of Contents
1. Applicability Statement . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 5
6. Hints for Multiple Identities . . . . . . . . . . . . . . . 6
7. Requesting Privacy . . . . . . . . . . . . . . . . . . . . . 6
8. User Agent Server Behavior . . . . . . . . . . . . . . . . . 7
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 7
9.1 The P-Asserted-Identity Header . . . . . . . . . . . . 8
9.2 The P-Preferred-Identity Header . . . . . . . . . . . . 8
9.3 The "id" Privacy Type . . . . . . . . . . . . . . . . . 9
Jennings, et. al. Informational [Page 1]
RFC 3325 SIP Asserted Identity November 2002
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1 Network Asserted Identity passed to trusted gateway . . 9
10.2 Network Asserted Identity Withheld . . . . . . . . . . 11
11. Example of Spec(T) . . . . . . . . . . . . . . . . . . . . . 13
12. Security Considerations . . . . . . . . . . . . . . . . . . 14
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
13.1 Registration of new SIP header fields . . . . . . . . . 14
13.2 Registration of "id" privacy type for SIP Privacy header 15
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
Normative References . . . . . . . . . . . . . . . . . . . . 15
Informational References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
1. Applicability Statement
This document describes private extensions to SIP [1] that enable a
network of trusted SIP servers to assert the identity of end users or
end systems, and to convey indications of end-user requested privacy.
The use of these extensions is only applicable inside a 'Trust
Domain' as defined in Short term requirements for Network Asserted
Identity [5]. Nodes in such a Trust Domain are explicitly trusted by
its users and end-systems to publicly assert the identity of each
party, and to be responsible for withholding that identity outside of
the Trust Domain when privacy is requested. The means by which the
network determines the identity to assert is outside the scope of
this document (though it commonly entails some form of
authentication).
A key requirement of [5] is that the behavior of all nodes within a
given Trust Domain 'T' is known to comply to a certain set of
specifications known as 'Spec(T)'. Spec(T) MUST specify behavior for
the following:
1. The manner in which users are authenticated
2. The mechanisms used to secure the communication among nodes within
the Trust Domain
3. The mechanisms used to secure the communication between UAs and
nodes within the Trust Domain
Jennings, et. al. Informational [Page 2]
RFC 3325 SIP Asserted Identity November 2002
4. The manner used to determine which hosts are part of the Trust
Domain
5. The default privacy handling when no Privacy header field is
present
6. That nodes in the Trust Domain are compliant to SIP [1]
7. That nodes in the Trust Domain are compliant to this document
8. Privacy handling for identity as described in Section 7.
An example of a suitable Spec(T) is shown in Section 11.
This document does NOT offer a general privacy or identity model
suitable for inter-domain use or use in the Internet at large. Its
assumptions about the trust relationship between the user and the
network may not apply in many applications. For example, these
extensions do not accommodate a model whereby end users can
independently assert their identity by use of the extensions defined
here. Furthermore, since the asserted identities are not
cryptographically certified, they are subject to forgery, replay, and
falsification in any architecture that does not meet the requirements
of [5].
The asserted identities also lack an indication of who specifically
is asserting the identity, and so it must be assumed that the Trust
Domain is asserting the identity. Therefore, the information is only
meaningful when securely received from a node known to be a member of
the Trust Domain.
Despite these limitations, there are sufficiently useful specialized
deployments that meet the assumptions described above, and can accept
the limitations that result, to warrant informational publication of
this mechanism. An example deployment would be a closed network
which emulates a traditional circuit switched telephone network.
2. Conventions
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 [3].
Throughout this document requirements for or references to proxy
servers or proxy behavior apply similarly to other intermediaries
within a Trust Domain (ex: B2BUAs).
Jennings, et. al. Informational [Page 3]
RFC 3325 SIP Asserted Identity November 2002
The terms Identity, Network Asserted Identity and Trust Domain in
this document have meanings as defined in [5].
3. Introduction
Various providers offering a telephony service over IP networks have
selected SIP as a call establishment protocol. Their environments
require a way for trusted network elements operated by the service
providers (for example SIP proxy servers) to communicate the identity
of the subscribers to such a service, yet also need to withhold this
information from entities that are not trusted when necessary. Such
networks typically assume some level of transitive trust amongst
providers and the devices they operate.
These networks need to support certain traditional telephony services
and meet basic regulatory and public safety requirements. These
include Calling Identity Delivery services, Calling Identity Delivery
Blocking, and the ability to trace the originator of a call. While
baseline SIP can support each of these services independently,
certain combinations cannot be supported without the extensions
described in this document. For example, a caller that wants to
maintain privacy and consequently provides limited information in the
SIP From header field will not be identifiable by recipients of the
call unless they rely on some other means to discover the identity of
the caller. Masking identity information at the originating user
agent will prevent certain services, e.g., call trace, from working
in the Public Switched Telephone Network (PSTN) or being performed at
intermediaries not privy to the authenticated identity of the user.
This document attempts to provide a network asserted identity service
using a very limited, simple mechanism, based on requirements in [5].
This work is derived from a previous attempt, [6], to solve several
problems related to privacy and identity in Trust Domains. A more
comprehensive mechanism, [7] which uses cryptography to address this
problem is the subject of current study by the SIP working group.
Providing privacy in a SIP network is more complicated than in the
PSTN. In SIP networks, the participants in a session are typically
able to exchange IP traffic directly without involving any SIP
service provider. The IP addresses used for these sessions may
themselves reveal private information. A general purpose mechanism
for providing privacy in a SIP environment is discussed in [2]. This
document applies that privacy mechanism to the problem of network
asserted identity.
Jennings, et. al. Informational [Page 4]
RFC 3325 SIP Asserted Identity November 2002
4. Overview
The mechanism proposed in this document relies on a new header field
called 'P-Asserted-Identity' that contains a URI (commonly a SIP URI)
and an optional display-name, for example:
P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
A proxy server which handles a message can, after authenticating the
originating user in some way (for example: Digest authentication),
insert such a P-Asserted-Identity header field into the message and
forward it to other trusted proxies. A proxy that is about to
forward a message to a proxy server or UA that it does not trust MUST
remove all the P-Asserted-Identity header field values if the user
requested that this information be kept private. Users can request
this type of privacy as described in Section 7.
The formal syntax for the P-Asserted-Identity header is presented in
Section 9.
5. Proxy Behavior
A proxy in a Trust Domain can receive a message from a node that it
trusts, or a node that it does not trust. When a proxy receives a
message from a node it does not trust and it wishes to add a P-
Asserted-Identity header field, the proxy MUST authenticate the
originator of the message, and use the identity which results from
this authentication to insert a P-Asserted-Identity header field into
the message.
If the proxy receives a message (request or response) from a node
that it trusts, it can use the information in the P-Asserted-Identity
header field, if any, as if it had authenticated the user itself.
If there is no P-Asserted-Identity header field present, a proxy MAY
add one containing at most one SIP or SIPS URI, and at most one tel
URL. If the proxy received the message from an element that it does
not trust and there is a P-Asserted-Identity header present which
contains a SIP or SIPS URI, the proxy MUST replace that SIP or SIPS
URI with a single SIP or SIPS URI or remove this header field.
Similarly, if the proxy received the message from an element that it
does not trust and there is a P-Asserted-Identity header present
which contains a tel URI, the proxy MUST replace that tel URI with a
single tel URI or remove the header field.
When a proxy forwards a message to another node, it must first
determine if it trusts that node or not. If it trusts the node, the
proxy does not remove any P-Asserted-Identity header fields that it
Jennings, et. al. Informational [Page 5]
RFC 3325 SIP Asserted Identity November 2002
generated itself, or that it received from a trusted source. If it
does not trust the element, then the proxy MUST examine the Privacy
header field (if present) to determine if the user requested that
asserted identity information be kept private.
6. Hints for Multiple Identities
If a P-Preferred-Identity header field is present in the message that
a proxy receives from an entity that it does not trust, the proxy MAY
use this information as a hint suggesting which of multiple valid
identities for the authenticated user should be asserted. If such a
hint does not correspond to any valid identity known to the proxy for
that user, the proxy can add a P-Asserted-Identity header of its own
construction, or it can reject the request (for example, with a 403
Forbidden). The proxy MUST remove the user-provided P-Preferred-
Identity header from any message it forwards.
A user agent only sends a P-Preferred-Identity header field to proxy
servers in a Trust Domain; user agents MUST NOT populate the P-
Preferred-Identity header field in a message that is not sent
directly to a proxy that is trusted by the user agent. Were a user
agent to send a message containing a P-Preferred-Identity header
field to a node outside a Trust Domain, then the hinted identity
might not be managed appropriately by the network, which could have
negative ramifications for privacy.
7. Requesting Privacy
Parties who wish to request the removal of P-Asserted-Identity header
fields before they are transmitted to an element that is not trusted
may add the "id" privacy token defined in this document to the
Privacy header field. The Privacy header field is defined in [6].
If this token is present, proxies MUST remove all the P-Asserted-
Identity header fields before forwarding messages to elements that
are not trusted. If the Privacy header field value is set to "none"
then the proxy MUST NOT remove the P-Asserted-Identity header fields.
When a proxy is forwarding the request to an element that is not
trusted and there is no Privacy header field, the proxy MAY include
the P-Asserted-Identity header field or it MAY remove it. This
decision is a policy matter of the Trust Domain and MUST be specified
in Spec(T). It is RECOMMENDED that the P-Asserted-Identity header
fields SHOULD NOT be removed unless local privacy policies prevent
it, because removal may cause services based on Asserted Identity to
fail.
Jennings, et. al. Informational [Page 6]
RFC 3325 SIP Asserted Identity November 2002
However, it should be noted that unless all users of the Trust Domain
have access to appropriate privacy services, forwarding of the P-
Asserted-Identity may result in disclosure of information which the
user has not requested and cannot prevent. It is therefore STRONGLY
RECOMMENDED that all users have access to privacy services as
described in this document.
Formal specification of the "id" Privacy header priv-value is
described in Section 9.3. Some general guidelines for when users
require privacy are given in [2].
If multiple P-Asserted-Identity header field values are present in a
message, and privacy of the P-Asserted-Identity header field is
requested, then all instances of the header field values MUST be
removed before forwarding the request to an entity that is not
trusted.
8. User Agent Server Behavior
Typically, a user agent renders the value of a P-Asserted-Identity
header field that it receives to its user. It may consider the
identity provided by a Trust Domain to be privileged, or
intrinsically more trustworthy than the From header field of a
request. However, any specific behavior is specific to
implementations or services. This document also does not mandate any
user agent handling for multiple P-Asserted-Identity header field
values that happen to appear in a message (such as a SIP URI
alongside a tel URL).
However, if a User Agent Server receives a message from a previous
element that it does not trust, it MUST NOT use the P-Asserted-
Identity header field in any way.
If a UA is part of the Trust Domain from which it received a message
containing a P-Asserted-Identity header field, then it can use the
value freely but it MUST ensure that it does not forward the
information to any element that is not part of the Trust Domain, if
the user has requested that asserted identity information be kept
private.
If a UA is not part of the Trust Domain from which it received a
message containing a P-Asserted-Identity header field, then it can
assume this information does not need to be kept private.
9. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-2234 [4].
Jennings, et. al. Informational [Page 7]
RFC 3325 SIP Asserted Identity November 2002
9.1 The P-Asserted-Identity Header
The P-Asserted-Identity header field is used among trusted SIP
entities (typically intermediaries) to carry the identity of the user
sending a SIP message as it was verified by authentication.
PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value
*(COMMA PAssertedID-value)
PAssertedID-value = name-addr / addr-spec
A P-Asserted-Identity header field value MUST consist of exactly one
name-addr or addr-spec. There may be one or two P-Asserted-Identity
values. If there is one value, it MUST be a sip, sips, or tel URI.
If there are two values, one value MUST be a sip or sips URI and the
other MUST be a tel URI. It is worth noting that proxies can (and
will) add and remove this header field.
This document adds the following entry to Table 2 of [1]:
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-Asserted-Identity adr - o - o o -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
o o o - - -
9.2 The P-Preferred-Identity Header
The P-Preferred-Identity header field is used from a user agent to a
trusted proxy to carry the identity the user sending the SIP message
wishes to be used for the P-Asserted-Header field value that the
trusted element will insert.
PPreferredID = "P-Preferred-Identity" HCOLON PPreferredID-value
*(COMMA PPreferredID-value)
PPreferredID-value = name-addr / addr-spec
A P-Preferred-Identity header field value MUST consist of exactly one
name-addr or addr-spec. There may be one or two P-Preferred-Identity
values. If there is one value, it MUST be a sip, sips, or tel URI.
If there are two values, one value MUST be a sip or sips URI and the
other MUST be a tel URI. It is worth noting that proxies can (and
will) remove this header field.
Jennings, et. al. Informational [Page 8]
RFC 3325 SIP Asserted Identity November 2002
This document adds the following entry to Table 2 of [1]:
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-Preferred-Identity adr - o - o o -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
o o o - - -
9.3 The "id" Privacy Type
This specification adds a new privacy type ("priv-value") to the
Privacy header, defined in [2]. The presence of this privacy type in
a Privacy header field indicates that the user would like the Network
Asserted Identity to be kept private with respect to SIP entities
outside the Trust Domain with which the user authenticated. Note
that a user requesting multiple types of privacy MUST include all of
the requested privacy types in its Privacy header field value.
priv-value = "id"
Example:
Privacy: id
10. Examples
10.1 Network Asserted Identity passed to trusted gateway
In this example, proxy.cisco.com creates a P-Asserted-Identity header
field from an identity it discovered from SIP Digest authentication.
It forwards this information to a trusted proxy which forwards it to
a trusted gateway. Note that these examples consist of partial SIP
messages that illustrate only those headers relevant to the
authenticated identity problem.
* F1 useragent.cisco.com -> proxy.cisco.com
INVITE sip:+14085551212@cisco.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-123
To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Max-Forwards: 70
Privacy: id
Jennings, et. al. Informational [Page 9]
RFC 3325 SIP Asserted Identity November 2002
* F2 proxy.cisco.com -> useragent.cisco.com
SIP/2.0 407 Proxy Authorization
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-123
To: <sip:+14085551212@cisco.com>;tag=123456
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Proxy-Authenticate: .... realm="sip.cisco.com"
* F3 useragent.cisco.com -> proxy.cisco.com
INVITE sip:+14085551212@cisco.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124
To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 70
Privacy: id
Proxy-Authorization: .... realm="sip.cisco.com" user="fluffy"
* F4 proxy.cisco.com -> proxy.pstn.net (trusted)
INVITE sip:+14085551212@proxy.pstn.net SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124
Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc
To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 69
P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
P-Asserted-Identity: tel:+14085264000
Privacy: id
Jennings, et. al. Informational [Page 10]
RFC 3325 SIP Asserted Identity November 2002
* F5 proxy.pstn.net -> gw.pstn.net (trusted)
INVITE sip:+14085551212@gw.pstn.net SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124
Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc
Via: SIP/2.0/TCP proxy.pstn.net;branch=z9hG4bK-a1b2
To: <sip:+14085551212@cisco.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 68
P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
P-Asserted-Identity: tel:+14085264000
Privacy: id
10.2 Network Asserted Identity Withheld
In this example, the User Agent sends an INVITE that indicates it
would prefer the identity sip:fluffy@cisco.com to the first proxy,
which authenticates this with SIP Digest. The first proxy creates a
P-Asserted-Identity header field and forwards it to a trusted proxy
(outbound.cisco.com). The next proxy removes the P-Asserted-Identity
header field and the request for Privacy before forwarding this
request onward to the biloxi.com proxy server which it does not
trust.
* F1 useragent.cisco.com -> proxy.cisco.com
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a111
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Max-Forwards: 70
Privacy: id
P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
* F2 proxy.cisco.com -> useragent.cisco.com
SIP/2.0 407 Proxy Authorization
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a111
To: <sip:bob@biloxi.com>;tag=123456
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 1 INVITE
Proxy-Authenticate: .... realm="cisco.com"
Jennings, et. al. Informational [Page 11]
RFC 3325 SIP Asserted Identity November 2002
* F3 useragent.cisco.com -> proxy.cisco.com
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 70
Privacy: id
P-Preferred-Identity: "Cullen Jennings" <sip:fluffy@cisco.com>
Proxy-Authorization: .... realm="cisco.com" user="fluffy"
* F4 proxy.cisco.com -> outbound.cisco.com (trusted)
INVITE sip:bob@biloxi SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 69
P-Asserted-Identity: "Cullen Jennings" <sip:fluffy@vovida.org>
Privacy: id
* F5 outbound.cisco.com -> proxy.biloxi.com (not trusted)
INVITE sip:bob@biloxi SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234
Via: SIP/2.0/TCP outbound.cisco.com;branch=z9hG4bK-c345
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 68
Privacy: id
Jennings, et. al. Informational [Page 12]
RFC 3325 SIP Asserted Identity November 2002
* F6 proxy.biloxi.com -> bobster.biloxi.com
INVITE sip:bob@bobster.biloxi.com SIP/2.0
Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-a123
Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-b234
Via: SIP/2.0/TCP outbound.cisco.com;branch=z9hG4bK-c345
Via: SIP/2.0/TCP proxy.biloxi.com;branch=z9hG4bK-d456
To: <sip:bob@biloxi.com>
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
Call-ID: 245780247857024504
CSeq: 2 INVITE
Max-Forwards: 67
Privacy: id
11. Example of Spec(T)
The integrity of the mechanism described in this document relies on
one node knowing (through configuration) that all of the nodes in a
Trust Domain will behave in a predetermined way. This requires the
predetermined behavior to be clearly defined and for all nodes in the
Trust Domain to be compliant. The specification set that all nodes
in a Trust Domain T must comply with is termed 'Spec(T)'.
The remainder of this section presents an example Spec(T), which is
not normative in any way.
1. Protocol requirements
The following specifications MUST be supported:
1. RFC 3261
2. RFC 3325
2. Authentication requirements
Users MUST be authenticated using SIP Digest Authentication.
3. Security requirements
Connections between nodes within the Trust Domain and between
UAs and nodes in the Trust Domain MUST use TLS using a cipher
suite of RSA_WITH_AES_128_CBC_SHA1. Mutual authentication
between nodes in the trust domain MUST be performed and
confidentiality MUST be negotiated.
Jennings, et. al. Informational [Page 13]
RFC 3325 SIP Asserted Identity November 2002
4. Scope of Trust Domain
The Trust Domain specified in this agreement consists of hosts
which posses a valid certificate which is a) signed by
examplerootca.org; b) whose subjectAltName ends with one of the
following domain names: trusted.div1.carrier-a.net,
trusted.div2.carrier-a.net, sip.carrier-b.com; and c) whose
domain name corresponds to the hostname in the subjectAltName
in the certificate.
5. Implicit handling when no Privacy header is present
The elements in the trust domain must support the 'id' privacy
service therefore absence of a Privacy header can be assumed to
indicate that the user is not requesting any privacy. If no
Privacy header field is present in a request, elements in this
Trust Domain MUST act as if no privacy is requested.
12. Security Considerations
The mechanism provided in this document is a partial consideration of
the problem of identity and privacy in SIP. For example, these
mechanisms provide no means by which end users can securely share
identity information end-to-end without a trusted service provider.
Identity information that the user designates as 'private' can be
inspected by any intermediaries participating in the Trust Domain.
This information is secured by transitive trust, which is only as
reliable as the weakest link in the chain of trust.
When a trusted entity sends a message to any destination with that
party's identity in a P-Asserted-Identity header field, the entity
MUST take precautions to protect the identity information from
eavesdropping and interception to protect the confidentiality and
integrity of that identity information. The use of transport or
network layer hop-by-hop security mechanisms, such as TLS or IPSec
with appropriate cipher suites, can satisfy this requirement.
13. IANA Considerations
13.1 Registration of new SIP header fields
This document defines two new private SIP header fields, "P-
Asserted-Identity" and "P-Preferred-Identity". As recommended by the
policy of the Transport Area, these headers have been registered by
the IANA in the SIP header registry, using the RFC number of this
document as its reference.
Jennings, et. al. Informational [Page 14]
RFC 3325 SIP Asserted Identity November 2002
Name of Header: P-Asserted-Identity
Short form: none
Registrant: Cullen Jennings
fluffy@cisco.com
Normative description:
Section 9.1 of this document
Name of Header: P-Preferred-Identity
Short form: none
Registrant: Cullen Jennings
fluffy@cisco.com
Normative description:
Section 9.2 of this document
13.2 Registration of "id" privacy type for SIP Privacy header
Name of privacy type: id
Short Description: Privacy requested for Third-Party Asserted
Identity
Registrant: Cullen Jennings
fluffy@cisco.com
Normative description:
Section 9.3 of this document
14. Acknowledgements
Thanks to Bill Marshall and Flemming Andreason [6], Mark Watson [5],
and Jon Peterson [7] for authoring drafts which represent the bulk of
the text making up this document. Thanks to many people for useful
comments including Jonathan Rosenberg, Rohan Mahy and Paul Kyzivat.
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] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
Jennings, et. al. Informational [Page 15]
RFC 3325 SIP Asserted Identity November 2002
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
Informational References
[5] Watson, M., "Short Term Requirements for Network Asserted
Identity", RFC 3324, November 2002.
[6] Andreasen, F., "SIP Extensions for Network-Asserted Caller
Identity and Privacy within Trusted Networks", Work in Progress.
[7] Peterson, J., "Enhancements for Authenticated Identity Management
in the Session Initiation Protocol (SIP)", Work in Progress.
Jennings, et. al. Informational [Page 16]
RFC 3325 SIP Asserted Identity November 2002
Authors' Addresses
Cullen Jennings
Cisco Systems
170 West Tasman Drive
MS: SJC-21/3
San Jose, CA 95134
USA
Phone: +1 408 527-9132
EMail: fluffy@cisco.com
Jon Peterson
NeuStar, Inc.
1800 Sutter Street, Suite 570
Concord, CA 94520
USA
Phone: +1 925/363-8720
EMail: Jon.Peterson@NeuStar.biz
Mark Watson
Nortel Networks
Maidenhead Office Park (Bray House)
Westacott Way
Maidenhead, Berkshire
England
Phone: +44 (0)1628-434456
EMail: mwatson@nortelnetworks.com
Jennings, et. al. Informational [Page 17]
RFC 3325 SIP Asserted Identity November 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jennings, et. al. Informational [Page 18]
|