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

From: "Sharon Laivand" <[email-masked]>
Date: Sun, 16 Jul 2006 16:54:36 +0300

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:[email-masked]] 
Sent: Tuesday, March 21, 2006 2:26 AM
To: [email-masked]
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
[email-masked] for questions on current sip Use
[email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Aki Niemi <[email-masked]>
Date: Mon, 17 Jul 2006 06:08:14 -0400

> draft. Anyway I will be glad to constantly contribute to this draft.

Thanks for your feedback. Some comments inline.

> security-agreements to SIP dialogs using peer transport address.

The primary reason this is underspecified is that back when RFC 3329 was
in the works, we didn't have a clear architecture for this sort of
thing. 

We do now, as outbound and SIP identity both rely on a UA having a
"sentinel" of sorts in the network to whom it has a persistent security
association and can send and receive traffic in a secure, identity-safe
way. 

I would say the most common case is that this association is
bootstrapped using a REGISTER, which was, in fact, the assumption of RFC
3329 as well. Perhaps not that clearly stated, though.

> conclude the choice made by the client and will release other resources.

That is a possible solution, although I've since come to believe that
choice in these sorts of situations is a bug and not a feature. This
becomes especially hairy if there would be need to indicate preference
accross different security mechanisms. Example: I am willing to do TLS,
but only with the PSK cipher suites; otherwise, I want to do transport
mode IPsec with IKE; but if it fails then perhaps TLS with RSA one-way.

My suggestion in this case would be to *not* add TLS cipher suite
identifiers to sec-agree, but e.g., to only ever do negotiation in the
TLS handshake, effectively deprecating sec-agree...

> regular address resolution.

I agree. This is effectively what sip-outbound defines; the only missing
thing is to clarify the security agreement procedure and say that before
the setup of the secure channel is finished, the server would actually
not send any requests to the UA. This would actually be a natural
consequence of using a REGISTER to bootstrap the negotiation.

> allow negotiating the same security mechanism twice.

I think RFC 3329 does allow several ipsec-3gpp mechanisms with different
algorithms to be offered, even giving each one a different q-value for
preference. Of course, in addition to not being well documented, as you
add more supported algorithms, there is a combinatorial explosion
resulting in more and more (redundant) ipsec-3gpp mechanisms offered.

There's been a suggestion to change the 3GPP grammar to allow the hash
and cipher algorithms be represented as a comma-separated list, which
seems like a reasonable idea.

> look for Security-Server list in 4xx responses on client side.

I'm not sure how to reconcile this in specification -- I *think* anyone
actually implementing RFC 3329 is doing so to support the 3GPP TS. So in
reality, this may not be such a big issue, but rather a place where 3GPP
and/or we could clarify and document existing implementation practice.

That said, allowing Security-Server to appear in a 401 would better
accomodate using RFC 3329 with sip-outbound.

> security-agreement only if it arrived in a 494 response.

This is an interesting point. It might actually happen that a
REGISTER/407 be challenged again with a 401 and a Security-Server. In
which case the original (outbound) proxy would somehow need to be
accomodated.

I'm not sure how to address this... So let me ask a meta-question
instead. ;-) 

How do we want to approach addressing these issues? The rfc3329-issues
draft basically proposes three alternatives:

1) Document all of the found issues with suggestions of how to deal with
them in an RFC errata entry.

2) Do #1 and fix the d-ver calculation as an update to RFC3329.

3) Revise RFC 3329.

Personally, I'm inclined to go with #1, maybe #2, but definitely not #3.
Reason being something I mentioned already above; I think keeping IPsec
around as a potential way to secure SIP is not viable. I think TLS is a
much better suited for securing SIP hops, and especially here, limiting
the amount of choices makes interop better.

Also, one of the key benefits of RFC 3329 is that it protects against
bid-down; however, given most UAs in the wild today don't implement it
pre-empts that benefit pretty well at this point. We sort of missed the
boat on that one, unfortunately.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Jul 2006 16:25:32 -0400

> 3329 as well. Perhaps not that clearly stated, though.

When using Digest, I think it is *only* in conjunction with REGISTER 
that you can bootstrap a security association. Furthermore, it has to be 
a first-party REGISTER, where To and From (and/or P-Asserted-Identity) 
are the same. The reason is because Digest authenticates the *source* of 
the request, not the destination. For some request where source and 
destination are different, you can't in general know whether the success 
of the request is dependent on the source being able to authenticate.

For instance, suppose there was a REGISTER where From is Alice, and To 
is Bob. Bob might send a 401 challenge, and Alice might successfully 
respond to it. But that doesn't mean that any entity responsible for 
Alice believes this is Alice, it only means that Bob believes this is 
Alice. It could be that 'Bob' is just a hack server in the network that 
believes any answer to its challenges.

The end result is that 3rd party registrations are not allowed in IMS, 
and because of the design of the system support for them can't readily 
be added.

	Paul