RE: [Sip] Update to RFC3329, aka Security Agreement

["Sharon Laivand" <[e-mail]>]

Hi Aki and all...


This email follows my conversation with Gonzalo at last IETF 66th -
regarding RFC3329 issues.

Here are some issues we thought of. I wonder if it can assist your
draft. Anyway I will be glad to constantly contribute to this draft.

Here are the comments/additions to the issues:

1.	
RFC3329 describes how the same security-agreement is used in several
transactions, but does not specify the relations between those
transactions. For example, a security-agreement can be obtained via
OPTIONS transaction and then used by a call-leg. Since there is no
SIP-wise relation between those two SIP entities, a key for comparison
must be defined. This is extremely problematic on server side, because
any incoming transaction must be verified according to the
security-agreement used in previous (unrelated and even nonexistent)
transactions.
One possible solution that is not good for all cases: match of
security-agreements to SIP dialogs using peer transport address.

2.	
A client that obtained a security-agreement with the server is
responsible to select and initiate a security mechanism to use in
further requests. The security-agreement negotiation process, however,
does not necessarily indicate to the server what the client is about to
choose (for example, if the server is the initiator of the negotiation).

Possible Solution: The server will leave all resources open (for
example, IPsec ports) waiting for the first protected request from the
client. Once a request is received from the client, the server will
conclude the choice made by the client and will release other resources.


3.	
The security-agreement process indicates to the client which security
mechanism to use in its requests to the server. However, there are no
explicit instructions for the server on how to send requests to the
client. RFC3329 indicates the possibility to use the security that the
client obtained for requests from the server, but it does not specify
the correct behavior. Moreover, the server might want to send a request
to the client before the client initiated the security mechanism (see
2).
Possible solution: Once the client sends a protected request to the
server via TLS or IPSec connection, the server will store this
connection and use it in its requests to the client (connection reuse
alike). Before that, any request from the server will be sent using
regular address resolution.

4.	
RFC3329 does not discuss the possibility of several suggestions of the
same security mechanism in one negotiation (for example, suggesting
ipsec-3gpp with two different algorithms).
draft-niemi-rfc3329-issues-00.txt states that future standardization
will describe how it shell be done.
Possible solution: In the mean time, till this issue is fixed; do not
allow negotiating the same security mechanism twice.

5.	
RFC3329 requires security-agreement to be held upon 494 responses. 3GPP
TS.33.203 however, allows the security-agreement to be held on other
responses, specifically 401 responses that are generated by the second
hop. 
Possible solution: Allow in RFC 3329 negotiating upon any 4xx response,
i.e., can add Security-Sever list to 4xx responses on server side, and
look for Security-Server list in 4xx responses on client side.

6.	
Another problem arouse from point 4, where the 401 response may contain
Authentication info originating at a second hop, but (theoretically) may
also contain Authentication info that is part of the security-agreement
negotiation. It may not be possible to differ between the two.
Possible solution: Consider authentication information as part of a
security-agreement only if it arrived in a 494 response.

I will be glad to know what you think of these issues...

Thanks 

Sharon Laivand.




-----Original Message-----
From: Aki Niemi [mailto:[e-mail]] 
Sent: Tuesday, March 21, 2006 2:26 AM
To: [e-mail]
Subject: [Sip] Update to RFC3329, aka Security Agreement

All,

During the past couple of years, there have been a few reported issues
on RFC 3329, based on implementation experience.

I've gathered the set of issues in an I-D:
http://www.ietf.org/internet-drafts/draft-niemi-rfc3329-issues-00.txt

We've already talked about rfc3329bis among the authors, and we feel
this would be appropriate in order to straighten out the issues and
improve interop. Any comments are welcome.

Cheers,
Aki

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



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