[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Question on RFC3329
Gabor.Bajko@nokia.com wrote:
RFC3329, section 2.3.1 says:
" The server MUST check that the security mechanisms listed in the
Security-Verify header field of incoming requests correspond to its
static list of supported security mechanisms.", and further down:
" The server can proceed processing a particular request if, and only
if, the list was not modified. If modification of the list is
detected, the server MUST respond to the client with a 494 (Security
Agreement Required) response."
In case of Digest this makes sense. But in case the agreed security mechanism is IPSec or TLS, then the SIP layer will only receive the request if it was sent according to the previously agreed security rules (otherwise the lower layers discard it). So, even in case the Security Verify header is altered (e.g. mistakenly at insertion by the UA), the request passed the security checks. Then why the server must respond with 494 instead of accepting it?
Shouldn't that MUST be a SHOULD instead, as the server knows how reliable the security mechanism they agreed is without the Security-Verify content?
We discussed this while the draft was being worked on. In principle
you are right, but we felt that it would be better to make the
behaviour the same in all cases without special cases.
Jari
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip