Subject: [Sip] ID updated: draft-kaplan-sip-baiting-attack-02.txt

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 22 Feb 2008 12:31:00 -0500

FYI, the draft on the Baiting attack with RFC4474 has been updated:
http://www.ietf.org/internet-drafts/draft-kaplan-sip-baiting-attack-02.txt

I changed section 12.1 possible solution to the problem of the request being delivered to unintended recipients.

This new solution only works for true SIP ends, vs. to a PSTN-gateway, but based on the mailing list discussion so far that appears to be a behavior the WG may want in the end.
(Personally I feel one might as well then only make RFC4474 work for SIPS URIs with S/MIME bodies, but that's just personal opinion)

-hadriel

_______________________________________________
Sip mailing list  http://www.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: "Elwell, John" <[email-masked]>
Date: Fri, 22 Feb 2008 17:39:00 +0000

Hadriel,

You wrote:
> (Personally I feel one might as well then only make RFC4474 
> work for SIPS URIs with S/MIME bodies, but that's just 
> personal opinion)
[JRE] The purpose of RFC 4474 was to provide authentication without
requiring a certificate at the UA - S/MIME requires a certificate!

John

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 22 Feb 2008 12:44:41 -0500

I know.  It was a joke/wise-a$$ comment on the usefulness of this thing. :)
-hadriel

> -----Original Message-----
> From: Elwell, John [mailto:[email-masked]]
> Sent: Friday, February 22, 2008 12:39 PM
> To: Hadriel Kaplan; IETF SIP List
> Cc: Dan Wing
> Subject: RE: [Sip] ID updated: draft-kaplan-sip-baiting-attack-02.txt
>
> Hadriel,
>
> You wrote:

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 22 Feb 2008 09:55:57 -0800

> requiring a certificate at the UA - S/MIME requires a certificate!

S/MIME requires a separate body part, too.  But SIP neglected to
clearly require support for multipart MIME and many implmentations 
neglect to include support for multipart MIME.  Robert Sparks 
collected information on multipart MIME support a SIPit or two 
ago, <http://www.sipforum.org/content/view/294/171>:

   " This is how the endpoints answered how they supported
     multipart/mime:

       7%  I break if someone sends me multipart/mime
      30%  I pretend multipart mime doesn't exist if someone sends 
           it to me
      20%  I ignore multipart/mime, but will proxy it or hand it 
           to my application if it shows up
      17%  I try to do something useful with multipart/mime I 
           receive, but I never send it
       3%  I ignore multipart/mime I receive, but I try to send it 
           to do something useful
      20%  I try to do something useful with multipart/mime I 
           send and receive "

I expect any SIP functionality that relied on multipart MIME would have
disappointing results in the field unless these numbers vastly improve.  But
without multipart MIME messages, implementors have little reason to code or
test it.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 22 Feb 2008 09:56:39 -0800

> I know.  It was a joke/wise-a$$ comment on the usefulness of 

Sorry for my followup, then; the joke was lost in the translation
to pixels.  :-)

-d