Subject: [Sip] e2m security: error code

From: Kumiko Ono <[email-masked]>
Date: Fri, 18 Mar 2005 17:55:49 -0500

At the SIP meeting last Tuesday, we discussed two issues of e2m security. 
I would like to resolve the issue that had no consensus. 

Issue:
An error response for proxy to a UAC for combined condition, requiring 
decryption (disclosure of message) and signature simultaneously.

Followings are the options I presented at Minneapolis:
Option1: A new error response
Option2: An existing error response(493) with Warning header
Option3: Existing error responses, one task at time

At the meeting, we had a consensus that when UA signs the body it should 
place the signature inside of the encrypted body, which means the proxy 
has no way to know the existence of signature until it is able to 
decrypt the message.

By using option 3, the proxy can ask for diclosure first, find out if 
the message has a signature attached, and respond with another error 
requesting signature when the message lacks it. This can be done and it 
is general procedure of proxy, but the number of messages exchanged will 
increases as it needs to respond twice when signature is not present.

Option 1 and 2 will resolve the downside mentioned with usage of option 
3. If the local security policy of the proxy requires both signature and 
disclosure, it can send error with combined reason, regardless of the 
possible existence of signature in the encrypted message.

With option 1, we need to define a new error code, such as 496 
"Undecipherable and signature required". The error condition assumes 
that the signature is lackin. Additionaly, once introducing a new code 
for combined reasons, we might need more new codes for other 
combinations. Therefore, I don't advocate option 1. 

With option 2, we need to define a three-digit warning-code. As section 
20.43 in RFC3261 says, 
 >The Warning header field isused to carry additional information about the 
status of a response. The currently-defined "warn-code"s are induced by 
the SDP.
This leads me to think that we can set a new warn-code that is induced 
by non-SDP. However, section 27.2 restricts the possible failures 
resulting from a SDP problem. 

If the reasoning restriction is not too stringent, we can define the 
following new warn-code, such as 340. However, it is strange to 
introduce a new warn-code that has the same meaning as that of the 
existing error code. Therefore, I am okay to go with option 3, not 
option 2. 

Your feedback will be very much appreciated.

Thanks,
--
Kumiko Ono

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Shida Schubert" <[email-masked]>
Date: Wed, 30 Mar 2005 15:30:04 -0800

Hi Kumiko;

 As I recall, it was mentioned several times at Minneapolis to make an 
effort to enforce the use of SIP Identity, to provide an integrity 
protection.

 According to my, not always accurate recollection, people were even 
alluding to mandate the use of SIP Identity in the future.

 Now, if you can use and depend on SIP Identity as a way to provide 
integrity protection, which in current spec allows proxy to verify its
validity, you only have to be concerned about a scenario where 
SIP Identity is not attached to an encrypted message(Another beauty 
of SIP Identity is that the signature is in the header therefore, 
you don't even have to decrypt to find the signature as you do with
the current e2m).

 In the scenario mentioned above, I think it would be okay to have extra
messages exchanged as it will be a rare case for this to take place, when
and if
The SIP Identity is mandated, which I do hope happens in near future.

 So considering what I stated above, I prefer option 3.

 Thanks & Regards
  Shida Schubert

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Kumiko
> Ono
> Sent: Friday, March 18, 2005 2:56 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: [Sip] e2m security: error code
>