📄 rfc3903 session initiation protocol (sip) extension.txt
字号:
further reduce the notification traffic produced as a result of a
PUBLISH request.
14.3. Replay Attacks
Replaying a PUBLISH request can have detrimental effects. An
attacker may be able to perform any event state publication it
witnessed being performed at some point in the past, by replaying
that PUBLISH request. Among other things, such a replay message may
Niemi Standards Track [Page 22]
RFC 3903 SIP Event State Publication October 2004
be used to spoof old event state information, although a versioning
mechanism, e.g., a timestamp, in the state information may help
mitigate such an attack.
To prevent replay attacks, implementations MUST support Digest
authentication with replay protection, as defined in RFC 3261 [4].
Further mechanisms for countering replay attacks are discussed in SIP
[4].
14.4. Man in the Middle Attacks
Even with authentication, man-in-the-middle attacks using PUBLISH may
be used to install arbitrary event state information, modify or
remove existing event state information in publications, or even
remove event state altogether at an ESC.
To prevent such attacks, implementations SHOULD, at a minimum,
provide integrity protection across the To, From, Event, SIP-If-
Match, Route, and Expires header fields and the bodies of PUBLISH
requests.
If the ESC receives event state in a PUBLISH request which is
integrity protected using a security association that is not with the
ESC (e.g., integrity protection is applied end-to-end, from publisher
to subscriber), the state agent coupled with the ESC MUST NOT modify
the event state before exposing it to the subscribers of this event
state in NOTIFY requests. This is to preserve the end-to-end
integrity of the event state.
For integrity protection, ESCs MUST implement TLS [8], and MUST
support both mutual and one-way authentication, and MUST also support
the SIPS URI scheme defined in SIP [4]. EPAs SHOULD be capable of
initiating TLS and SHOULD support the SIPS URI scheme. ESCs and EPAs
MAY support S/MIME [9] for integrity protection, as defined in SIP
[4].
14.5. Confidentiality
The state information contained in a PUBLISH message may potentially
contain sensitive information. Implementations MAY encrypt such
information to ensure confidentiality.
For providing confidentiality, ESCs MUST implement TLS [8], MUST
support both mutual and one-way authentication, and MUST also support
the SIPS URI scheme defined in SIP [4]. EPAs SHOULD be capable of
initiating TLS and SHOULD support the SIPS URI scheme. ESCs and EPAs
MAY support S/MIME [9] for encryption of event state information, as
defined in SIP [4].
Niemi Standards Track [Page 23]
RFC 3903 SIP Event State Publication October 2004
15. Examples
This section shows an example of using the PUBLISH method for
publishing a presence document from a presence user agent to a
presence agent. The watcher in this example is subscribing to the
presentity's presence information from the PA. The PUA may also
SUBSCRIBE to its own presence to see the composite presence state
exposed by the PA. This is an optional but likely step for the PUA,
and is not shown in this example.
When the value of the Content-Length header field is "..." this means
that the value should be whatever the computed length of the body is.
PUA PA WATCHER
(EPA) (ESC)
| | |
| | <---- M1: SUBSCRIBE --- |
| | |
| | ----- M2: 200 OK -----> |
| | |
| | ----- M3: NOTIFY -----> |
| | |
| | <---- M4: 200 OK ------ |
| | |
| | |
| ---- M5: PUBLISH ---> | |
| | |
| <--- M6: 200 OK ---- | |
| | |
| | ----- M7: NOTIFY -----> |
| | |
| | <---- M8: 200 OK ------ |
| | |
| ---- M9: PUBLISH ---> | |
| | |
| <--- M10: 200 OK --- | |
| | |
| | |
| --- M11: PUBLISH ---> | |
| | |
| <-- M12: 200 OK ---- | |
| | |
| | ----- M13: NOTIFY ----> |
| | |
| | <---- M14: 200 OK ----- |
| | |
Niemi Standards Track [Page 24]
RFC 3903 SIP Event State Publication October 2004
Message flow:
M1: The watcher initiates a new subscription to the
presentity@example.com's presence agent.
SUBSCRIBE sip:presentity@example.com SIP/2.0
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds7
To: <sip:presentity@example.com>
From: <sip:watcher@example.com>;tag=12341234
Call-ID: 12345678@host.example.com
CSeq: 1 SUBSCRIBE
Max-Forwards: 70
Expires: 3600
Event: presence
Contact: sip:user@host.example.com
Content-Length: 0
M2: The presence agent for presentity@example.com processes the
subscription request and creates a new subscription. A 200 (OK)
response is sent to confirm the subscription.
SIP/2.0 200 OK
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds7
;received=192.0.2.1
To: <sip:presentity@example.com>;tag=abcd1234
From: <sip:watcher@example.com>;tag=12341234
Call-ID: 12345678@host.example.com
CSeq: 1 SUBSCRIBE
Contact: sip:pa.example.com
Expires: 3600
Content-Length: 0
M3: In order to complete the process, the presence agent sends the
watcher a NOTIFY with the current presence state of the
presentity.
NOTIFY sip:user@host.example.com SIP/2.0
Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@host.example.com
CSeq: 1 NOTIFY
Max-Forwards: 70
Event: presence
Subscription-State: active; expires=3599
Contact: sip:pa.example.com
Content-Type: application/pidf+xml
Content-Length: ...
Niemi Standards Track [Page 25]
RFC 3903 SIP Event State Publication October 2004
[PIDF document]
M4: The watcher confirms receipt of the NOTIFY request.
SIP/2.0 200 OK
Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2
;received=192.0.2.2
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@host.example.com
CSeq: 1 NOTIFY
M5: A presence user agent (acting for the presentity) initiates a
PUBLISH request to the presence agent in order to update it with
new presence information. The Expires header field indicates the
suggested duration for this event soft state.
PUBLISH sip:presentity@example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge
To: <sip:presentity@example.com>
From: <sip:presentity@example.com>;tag=1234wxyz
Call-ID: 81818181@pua.example.com
CSeq: 1 PUBLISH
Max-Forwards: 70
Expires: 3600
Event: presence
Content-Type: application/pidf+xml
Content-Length: ...
[Published PIDF document]
M6: The presence agent receives, and accepts the presence
publication. The published data is incorporated into the
presentity's presence information.
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge
;received=192.0.2.3
To: <sip:presentity@example.com>;tag=1a2b3c4d
From: <sip:presentity@example.com>;tag=1234wxyz
Call-ID: 81818181@pua.example.com
CSeq: 1 PUBLISH
SIP-ETag: dx200xyz
Expires: 1800
M7: The presence agent determines that a reportable change has been
made to the presentity's presence information, and sends a
new presence notification to the watcher.
Niemi Standards Track [Page 26]
RFC 3903 SIP Event State Publication October 2004
NOTIFY sip:user@host.example.com SIP/2.0
Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK4cd42a
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@host.example.com
CSeq: 2 NOTIFY
Max-Forwards: 70
Event: presence
Subscription-State: active; expires=3400
Contact: sip:pa.example.com
Content-Type: application/pidf+xml
Content-Length: ...
[New PIDF document]
M8: The watcher confirms receipt of the NOTIFY request.
SIP/2.0 200 OK
Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK4cd42a
;received=192.0.2.2
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@host.example.com
CSeq: 2 NOTIFY
Content-Length: 0
M9: The PUA determines that the event state it previously published
is about to expire, and refreshes that event state.
PUBLISH sip:presentity@example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK771ash02
To: <sip:presentity@example.com>
From: <sip:presentity@example.com>;tag=1234kljk
Call-ID: 98798798@pua.example.com
CSeq: 1 PUBLISH
Max-Forwards: 70
SIP-If-Match: dx200xyz
Expires: 3600
Event: presence
Content-Length: 0
M10: The presence agent receives, and accepts the publication
refresh. The timers regarding the expiration of the specific
event state identified by the entity-tag are updated. As always,
the ESC returns an entity-tag in the response to a successful
PUBLISH. Note that no actual state change has occurred, so the
watchers will receive no NOTIFYs.
Niemi Standards Track [Page 27]
RFC 3903 SIP Event State Publication October 2004
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK771ash02
;received=192.0.2.3
To: <sip:presentity@example.com>;tag=2affde434
From: <sip:presentity@example.com>;tag⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -