Subject: [Sipping] Comments on of draft-saito-mmusic-sdp-ike-01.txt

From: [email-masked]
Date: Thu, 2 Aug 2007 16:43:33 -0400

I am not up to date on the security mechanisms of SIP nor of IKE, but
it does seem to me that this draft needs to spell out its security
mechanisms more exactly, so that a non-expert can see how the security
properties of the protocol are established.

For instance, it appears that when Home Router registers with SIP
Proxy, it has to present some authentication in order to obtain its
registration.  The details of this are not described.

When Remote Client sets up the TLS session over which it will send the
INVITE, presumably it uses SIP Proxy's presented certificate to verify
SIP Proxy's identity.

The exact mechanisms by which the SDP in the INVITE is secured doesn't
seem to be detailed, though the text refers to SIP identity and SIP
connected identity.  Also, the RFCs for those mechanisms are listed as
"informative", whereas they are clearly "normative" for this usage.

Overall, Remote Client needs to possess some way to authenticate
itself to SIP Proxy and/or Home Router, and from the point of view of
this mechanism as a whole, it is an infrastructure-organization
problem, but the details of that are not described -- all that is
mentioned is that Remote Client possesses a self-signed certificate,
but it does not seem to be assumed that Home Router knows the
certificate's contents a priori.

At some one point, the entire sequence of events and the successive
authentications needs to be listed so that one can verify its
soundness.

Nits:

In Figure 1, only a subset of steps are shown.  E.g., the sending of
an INVITE is step 2, but the prior establishment of a TLS connection
(by which SIP Proxy authenticates itself to Remote Client) is not
described.

Section 3 defines the "udp-setup" attribute by reference to RFC 4145,
but strictly, RFC 4145 defines the "setup" attribute.  The text should
state "The endpoints negotiate the value of "udp-setup" in the say way
that RFC 4145 describes negotiating the value of "setup"..." in order
to be accurate.

Dale

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

---

From: Makoto SAITO <[email-masked]>
Date: Wed, 08 Aug 2007 04:41:40 -0400

Thanks Dale,

I'm sorry for my late response.
My comments are in-line.

> properties of the protocol are established.

The essence of this draft is similar to comedia-tls (rfc4572),
so the security feature is also the same as it.
I simplified whole the document by omitting some specific mechanisms
and it may have confused many of you.

> INVITE, presumably it uses SIP Proxy's presented certificate to verify

That's true. In many cases, you will use TLS session for signaling path,
and it would be easier for many client devices to authenticate the proxy
server by certificate but use digest-auth for clients themselves.
However, this is not always necessary because some client might use
other security mechanisms for its signaling path.
So, I'll add the above security method as one of the examples.

> "informative", whereas they are clearly "normative" for this usage.

SIP identity and SIP connected identity are also the typical methods
to secure the contents of SDP. So I think I can describe it in detail
as one of the example scenarios. But I'm not sure it's normative
because we can make use of sdp-ike mechanism without using sip identity
in theory.

> authentications needs to be listed so that one can verify its

Thank you very much. Maybe I can add the entire sequence in the
update draft. However it will be a typical and simple SIP scenario,
so I believe it won't damage the soundness of the draft's concept.
In fact, it is the same as comedia-tls.

> that RFC 4145 describes negotiating the value of "setup"..." in order

As a few people said, it might be better to reuse "setup"
for UDP session without defining "udp-setup" attribute.

Thank you,

-- 
Makoto Saito