RE: SIP Identity using Media Path

Paul Kyzivat wrote:
> Dan,
> 
> I just took a look at this.

Thanks.

> I have a few questions:
> 
> 1) Because you only sign the selected attributes from the 
> SDP, the rest is not secured. That seems like an acceptable 
> restriction if you assume there will be a media-terminating 
> SBC in the path.
> 
> But what about other body parts? I gather they won't be 
> signed either. 

Right.

> That seems like a potential problem as we start to identify 
> need for various extra body parts.

That's a good point, which I hadn't considered.  

The existing SIP-Identity (RFC4474) could be used to sign such
SIP requests, so long as they don't contain any SDP bodyparts
(if they contain SDP bodyparts and RFC4474 signs them, you're
back at the problems with RFC4474 signatures being broken by
SBCs and B2BUAs).  So, this doesn't seem to be ideal.

What I would suggest, and can write up if it sounds sensical,
is to sign each individual non-SDP MIME part.  This would be
accomplished by creating two new SIP headers, "Identity-part",
which contains the Content-IDs of the non-SDP MIME parts
that are signed, and Identity-Part-Signature, which contains
the signature over those parts.

For example, if a SIP UA sent an Invite like this:

  INVITE ...
  From: Alice <at> example.com
  To: john <at> example.net
  Content-Type: multipart/mixed; boundary=X
  ...

  --X
  Content-Type: application/sdp

  v=0
  o=- 6418913922105372816 2105372818 IN IP4 192.0.2.1
  s=example2
  c=IN IP4 192.0.2.1
  t=0 0
  m=audio 54113 RTP/SAVP 0
  a=setup:active
  a=connection:new
  a=fingerprint:SHA-1
     4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB

  --X
  Content-Type: text/plain

  John, let's talk about the upcoming press release.

  --X--

The authentication service would add the SIP headers described in the
existing -sip-identity-media-00:

  Identity-Fingerprints:
      4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
  Identity-Media:
     "ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa
      ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn
      FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U="

and I am proposing it would add the missing Content-Id headers (so that each
MIME part can be clearly identified) and two new SIP headers (Identity-Part,
Identity-Part-Signature).  The 
Identity-Part-Signature contains a signature over all of the MIME bodyparts
listed in the Identity-Part header (shown below with "$" on the left-most
column):

  INVITE ...
  From: Alice <at> example.com
  To: john <at> example.net
  Content-Type: multipart/mixed; boundary=X
  Identity-Fingerprints:
      4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
  Identity-Media:
       "ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa
        ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn
        FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U="
  Identity-Part: ab111
  Identity-Part-Signature:
       "ncEjfecq2jefmceejcech3233rjfejncecjkeu3fjefje93jnakjjqknenceuHEc
        jfeqcnekueri283jfkjfcnencehutiujfe9383mjfejkequie839283jnecneqce
        q11jfjfkcaqncerEJCEJCMEQMCECEJKEFJEKFjejffke"
  ...

  --X
  Content-Type: application/sdp
  Content-Id: ab000

  v=0
  o=- 6418913922105372816 2105372818 IN IP4 192.0.2.1
  s=example2
  c=IN IP4 192.0.2.1
  t=0 0
  m=audio 54113 RTP/SAVP 0
  a=setup:active
  a=connection:new
  a=fingerprint:SHA-1
     4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB

  --X
$ Content-Type: text/plain
$ Content-Id: ab111
$
$ John, let's talk about the upcoming press release.
$
  --X--

Thoughts on this approach?

We might also consider using the authentication service's S/MIME keys (not
the UA's S/MIME keys), which may well be cleaner.

> 2) What about "offerless" initial INVITEs?
> 
> 3) What about messages that don't use SDP at all?

Both of these situations would be handled in the same way RFC4474
(SIP-Identity) handles them:

For offerless invites, you would rely on Connected-Identity to provide the
assertion of the initiator's identity.

For messages with no SDP, you can sign non-SDP bodyparts (as I describe
above).  If the message has no body to sign, there isn't any magic we can do
using the media path to authenticate the message came from the claimed peer
-- because of course there is no media path.  Both RFC4474 and RFC3893 (AIB)
share this same problem.  When there is no body, all you can do is sign
headers (including the Date: header) in an effort to prevent replay attacks.
This is what SIP-Identity-Media, RFC4474, and RFC3893 (AIB) all do.

-d

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip