Subject: [SIP] Authorization Header and content question

From: Bob Bell <[email-masked]>
Date: Wed, 17 Jan 2001 10:16:52 -0700

In studying section 14.1.2 of rfc2543bis-02, I have raised three questions 
relative to the use of digitally signed messages. The first is the message 
content that is to be signed.

In the second paragraph of the pgp-signature description, the order of 
processing is specified as "... the nonce (if present), realm, request 
method, request version, and header fields following the Authorization 
header and the message body, in the same order as they appear in the 
message. ... The signature is computed across the headers as sent, and the 
terminating CRLF. The CRLF following the Authorization header is NOT 
included in the signature."  There is Authorization header information 
which is extracted from within the header (notably the nonce and realm 
fields). Are those fields again processed while computing over the 
Authorization header?

The second question is related to the first in that it is obvious that the 
signature itself is not included in the signature. Is there any reason to 
include the Authorization header per se into the signature since the nonce 
and realm are already included? This would then totally exclude the 
Authorization header from the signature computation itself and perhaps make 
the description more understandable.

Third, in the informational draft entitled 
"draft-ietf-sip-call-flows-02.txt", section 2.1.x, there are several 
examples of messages containing Authorization headers. Each Authorization 
header is the last header in the message. Yet in rfc2543bis-02, in section 
14.1.2, the calculation of the signature is said to include all headers 
following the Authorization header and that "Receivers of signed SIP 
messages SHOULD discard any end-to-end header fields above the 
Authorization header, as they may have been maliciously added en route by a 
proxy." This would lead one to believe that all information contained in 
the REGISTER messages SHOULD be discarded. In studying the procedures 
outlined, I presume that the proper placement for the Authorization header 
is immediately following the Via header. Since the Via header is properly 
modified en route, its contents cannot be protected with a signature from 
the originating endpoint. All other end-to-end fields should however follow 
the Authorization header so as to be included in the signature and thus 
protected. Is my assumption correct?

One final question unrelated to the preceding ones. The rfc2543bis-02 
provides for methods of signing and thus authenticating requests from the 
user to the proxy. However, there is no inherent method of authenticating 
the proxy messaging. If the overhead of the IPSec security association is 
incurred, then, through means outside the protocol, such mutual 
authentication is possible. However, if the use of signatures is extended 
to include messages from the proxy, such mutual authentication could be had 
within the confines of the protocol itself without invoking other outside 
means. I believe this could be a valuable addition to the protocol.

Thanks for your help and consideration ---- Bob Bell

Bob Bell
Cisco Systems Inc.
801-294-3034(v)
801-294-3023(f)

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.