Subject: [Sip] Signing P-Asserted-Identity

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 7 Jul 2008 18:56:58 -0400

Howdy,
As the discussions about RFC4474 Identity, E.164, and all that seem of the type that will take a very long time to resolve, I've submitted an ID about a private extension for "Asserter Identity", which works in concert with the P-Asserted-Identity mechanism.  It works very similarly to RFC4474, but doesn't sign quite the same things, and can be used to sign TEL URI's, fwiw.

Comments welcomed, of course.

        Title           : Private Extensions to the Session Initiation Protocol (SIP) for Asserter Identification within Trusted Networks
        Author(s)       : H. Kaplan
        Filename        : draft-kaplan-sip-asserter-identity-00.txt
        Pages           : 18
        Date            : 2008-07-07

This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to identify the asserter of private user identity defined in RFC 3325.  The use of these extensions is only applicable inside a set of administrative domains with previously agreed-upon policies for generation, transport and usage of such information.
This document does NOT offer a general identity model suitable for use between different trust domains, or use in the Internet at large.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kaplan-sip-asserter-identity-00.txt

-hadriel
_______________________________________________
Sip mailing list  https://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: Tue, 08 Jul 2008 09:56:05 +0100

Hadriel,

This is an interesting draft, but I am not sure to what extent it
addresses the e2e identity issues discussed in
draft-elwell-sip-e2e-identity-important, even though that draft is
referenced in section 1.1 of your draft. If a request or response passes
through two or more trust domains, the UA will receive only the
assertion from the nearest trust domain. Also the P-Original-To header
field will not necessarily contain the original To value. By the way,
there is no syntax definition for P-Original-To.

A proxy in one trust domain might pass on PAI (and hence PASS) to an
untrusted proxy. According to RFC 3325, that second proxy, assuming it
likewise does not trust the first proxy, must remove PAI. Presumably it
would also be required to remove PASS headers. This is not clear in the
draft. Section 8 talks about forwarding to an untrusted proxy, but does
not talk about receiving from an untrusted proxy.

Presumably, after removing PAI and PASS headers from a message from an
untrusted node, a proxy could insert its own PAI and PASS headers. Hence
we end up only with hop-by-hop authenticated assertions still.

"For SIP responses, the P-Original-To URI value would 
   typically be the URI of the From header field. Details on the 
   generation of this header are provided in Section 10."
I assume that "this header" refers to P-Original-To. However, I can't
find anything on that in section 10.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hadriel Kaplan
> Sent: 07 July 2008 23:57
> To: [email-masked]
> Subject: [Sip] Signing P-Asserted-Identity
> 
> Howdy,
> As the discussions about RFC4474 Identity, E.164, and all 
> that seem of the type that will take a very long time to 
> resolve, I've submitted an ID about a private extension for 
> "Asserter Identity", which works in concert with the 
> P-Asserted-Identity mechanism.  It works very similarly to 
> RFC4474, but doesn't sign quite the same things, and can be 
> used to sign TEL URI's, fwiw.
> 
>         Title           : Private Extensions to the Session 
> Initiation Protocol (SIP) for Asserter Identification within 
> Trusted Networks
>         Author(s)       : H. Kaplan
> This document describes private extensions to the Session 
> Initiation Protocol (SIP) that enable a network of trusted 
> SIP servers to identify the asserter of private user identity 
> defined in RFC 3325.  The use of these extensions is only 
> applicable inside a set of administrative domains with 
> previously agreed-upon policies for generation, transport and 
> usage of such information.
> This document does NOT offer a general identity model 
> suitable for use between different trust domains, or use in 
> the Internet at large.
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 8 Jul 2008 11:37:43 -0400

> From: Elwell, John [mailto:[email-masked]]
>
> field will not necessarily contain the original To value.

PASS is intended to only address such issues in specific deployment scenarios, just as PAI is.  I don't think I said PASS was end-to-end in all scenarios - just for a given trust-domain, and yes the scope of PAI and PASS is tied.  The main scenario for its use would be one of a single trust-domain, including one where there are stub nodes/domains attached to that trust-domain but are not technically in it, and are not transits themselves.

For example, a scenario such as: A ---[ SP1 --- SP2 --- SP3 ]--- B
Where SP1/SP2/SP3 are all member of a single PAI trust domain, and A and B are endpoints or Enterprises.

If SP2 is not in the trust domain of SP1 or SP3, then following the rules of rfc3325, SP3 would not believe any PAI received from SP2 (or at least one that doesn't identify an identity in SP2).  If SP3 thus removes the PAI or changes its contents, it will invalidate the PASS signature clearly (which is a good thing essentially), if that's not also removed.  (and you point out something that should definitely be discussed in the draft)

But really PASS is only attesting to the Asserter's identity and what it claims the PAI/POT are.  If SP3 changes the PAI/POT, why shouldn't B believe SP3 over all the others?  It's the trust-domain it has a relationship with.  It's not optimal, but the whole issue is SP3 is claiming a different PAI/POT than what A/SP1/SP2 did.  Imagine this in the 4474 context - if SP3 changed the From/To, what should the behavior be?  The answer is "well SP3 shouldn't change those things", and likewise here.  The "good" part about this is if SP3 gets it wrong, then B knows who got it wrong and can complain to SP3.

The issue though I think you're trying to get to is the ability for an Enterprise to forward calls from outside its domain into service providers, which you've told me before would mean the service provider inserts a PAI which identifies the Enterprise rather than the true originator.  In other words that SP3 will insert a PAI identifying a "default" SP3 identity, even though the request came from A in the previous example.  In my mind that PAI behavior is clearly broken - it's not following rfc3325, and it's not really useful.  If TISPAN wants to make the PAI an ANI instead of a CLID, it should at least define a parameter to indicate it as such for such cases, because the receivers of that PAI will use it for caller-id display otherwise.  PASS signing the PAI in such a case only points out the bad behavior - if SP3 doesn't feel it should be signing such a PAI, then why is it generating such a PAI?

> By the way,

It's shocking how the ID submission tool removes entire sections.  Just kidding.  Yes good catch - will add it in next rev. :)

> not talk about receiving from an untrusted proxy.

Right, another good catch - will fix.  I need to say the PAI and PASS fates are shared.

> we end up only with hop-by-hop authenticated assertions still.

Yes, but not hop-by-hop, rather trust-domain by trust-domain.  It's not panacea, but it covers a lot of ground in the real world methinks, where so far the majority of usage has only one trust-domain (the PAI gets all the way through).

-hadriel

---

From: Michael Thomas <[email-masked]>
Date: Tue, 08 Jul 2008 11:36:53 -0700

I thought that the beauty of P-A-I was that my telco can happily claim that
I'm the Queen of the Night without all the bother of checking to see if
I'm a soprano, or can even sing that many notes in a row. So I guess
I don't see what the point is being extra sure that the fiction is a super
reliable fiction.

And since it seems to only be within a given administrative realm, why
isn't TLS or many other possible techniques adequate?

       Mike

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 8 Jul 2008 15:08:23 -0400

> From: Michael Thomas [mailto:[email-masked]]
>

It identifies who wrote the fiction, and the receiver can decide if they believe the writer (e.g., based on a reputation system); or if it is fiction can know who wrote it and let them know. (most operators don't intend to write fiction :)

And I should note 4474 has a similar issue - the signer can change the From to whatever before signing - except at least 4474 constrains the scope of that fictional identity to the signer's domain name in the URI.  In theory that makes it pretty good, because the signer can only lie about their own users, but in practice if the URI is treated as an E.164 then the scope isn't constrained.

> isn't TLS or many other possible techniques adequate?

It's not within a given administrative domain - it's within a PAI trust-domain, which in practice often contains multiple administrative domains.

-hadriel

---

From: Michael Thomas <[email-masked]>
Date: Tue, 08 Jul 2008 12:29:59 -0700

> And I should note 4474 has a similar issue - the signer can change the From to whatever before signing - except at least 4474 constrains the scope of that fictional identity to the signer's domain…

Indeed, DKIM has the same constraint as well.  What I'm not entirely
getting is why 4474 isn't sufficient for the overall goal. And if 4474
doesn't cover the needed headers, wouldn't a better fix be to change
4474 to allow more headers to be signed ala DKIM's h= tag instead
of rolling yet another scheme?

In any case, P-A-I still seems like a different animal than 822-like
addresses which at least can be anchored in a given domain. DKIM
has the capability of signing messages that don't necessarily correspond
to any outside header, but AFAIK that capability isn't being used for
much... which sort of implies that it's either useless which SIP should
avoid, or useful which SIP backfill. Since we don't know the answer
to that quesion, wouldn't it be better to wait and see?

       Mike

---

From: Dan York <[email-masked]>
Date: Tue, 8 Jul 2008 15:58:22 -0400

Mike,

On Jul 8, 2008, at 3:29 PM, Michael Thomas wrote:

> getting is why 4474 isn't sufficient for the overall goal.

See:

http://tools.ietf.org/rfcmarkup?doc=draft-elwell-sip-e2e-identity-important-00
http://tools.ietf.org/id/draft-kaplan-sip-uris-change-00.txt

They explain where RFC 4474 breaks in actual implementations.  (The  
key point being that devices in the network like SBCs change headers  
that are part of the 4474 Identity signature, thus invalidating the  
4474 identity.)

Regards,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 8 Jul 2008 16:18:00 -0400

> getting is why 4474 isn't sufficient for the overall goal.

That has been a source of debate for a couple years of mailing list traffic. :)
The problems identified so far, I think:
1) Most URI's are actually E.164's, either as Tel's in Sip disguise, or as real Tel's - and 4474 either can't apply to it, or shouldn't, or should - depending on who you ask and in what context.  But E.164 is the elephant in the room.
2) 4474 signs things which many real-world cases will break the signature of, and thus has a deployment problem (whether that's fixable, or by design, is another topic of debate).  But that's another elephant in the room, or maybe a lion, smaller but hairy.
3) 4474 is susceptible to cut/paste attacks - for example the baiting attack.  That one's more like a clown, annoying but probably not deadly.
4) 4474 requires 4916 for called-identity, which some people aren't happy with I think.  That one's more like a camel, a hump some people don't like the smell of.

At least I think that's the main tent.  So basically what we got here is a circus, with some of us trying to tame the animals, while others prefer to sit and enjoy the show. :)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 8 Jul 2008 16:25:01 -0400

> And if 4474

Some of it's the "headers", some the body, some the type of URI.  I'm all for a 4474bis, and I hope we can make one happen.  But if not, PASS may be useful for me.  At least so far PAI sure has seemed popular in my world.

> to that quesion, wouldn't it be better to wait and see?

Wait and see what?  You lost me there.

-hadriel

---

From: Michael Thomas <[email-masked]>
Date: Tue, 08 Jul 2008 14:12:16 -0700

> Wait and see what?  You lost me there.
Meaning that it's far from clear how fledgling reputation services are
going to use these identities. What exactly does a signed P-A-I mean
even if we had one? What might a receiver or third party do differently
vs. a signed from, say? Especially when you factor in that P-A-I is
big smelly hack?

Waiting-and-seeing what the reputation folks actually need versus guessing
what they might need, maybe, someday seems prudent to me. That's
doubly true because there's not been much if any uptake of 4474 and
I'm guessing that lack of coverage of P-A-I is not one of the reasons.
Concentrating on _that_ problem seem to me the paramount concern.

          Mike

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 8 Jul 2008 17:36:12 -0400

> vs. a signed from, say? Especially when you factor in that P-A-I is

Yes, another elephant. :)
A PASS-signed PAI means the asserter generated it for this message.  Right now we have multi-domain exchanges of SIP messages with PAI header fields being used for caller-id.  I don't know what-all a receiver might do with the signed information (though I could guess).  I am only offering to give it more information.  Some folks are telling me they would like to know that the caller-id is legit.  I can't.  I can only tell them that a node which generated a caller-id also owns a cert from a CA they trust, so they have some recourse if it ends up being wrong.  I have no (practical) way to verify the caller-id directly. (And neither does 4474 or DKIM)

> Concentrating on _that_ problem seem to me the paramount concern.

There has not been any uptake of 4474 for a bunch of reasons, not the least of which is there's no problem yet, and for some/many cases we know it won't work.  I have no doubt a PASS signature is not the be-all-end-all solution.  But I do know it takes years to get something spec'ed, implemented, tested, and deployed in any scale that will matter.  So I'm trying to do a short-cut, instead of waiting for a problem: thus, an informational P-header.

-hadriel

---

From: Michael Thomas <[email-masked]>
Date: Tue, 08 Jul 2008 15:11:07 -0700

> A PASS-signed PAI means the asserter generated it for this message.  Right now we have multi-domain exchanges of SIP messages with PAI header fields being used for caller-id.  I don't know what-all…

So let me get this, um, straight: what people really want is to be able
to trust the callerid but that's precisely what we can't provide. Hmm.
And many of things that you point out about breakage with 4474 is
not _really_ a fault of 4474 per se, it's that you're hoping essentially
for the impossible: having a signature survive through a b2bua sausage
factory.

Sounds all too familiar. I agree with the "blame me" stance, and I'm
not dissing the idea of 4474 being more flexible in what headers it
can sign. It's just that this is all very tangled with the possible,
the impossible and the unknown.
> There has not been any uptake of 4474 for a bunch of reasons, not the least of which is there's no problem yet, and for some/many cases we know it won't work.  I have no doubt a PASS signature is n…
A short cut! Run away! :)

Seriously, if you want a short cut, you too could hack on one of the open
source versions of DKIM and have something that can sign your P-A-I
(in a fit of dementia, I have actually DKIM-signed SIP messages for grins).
DKIM is probably less brittle than 4474, but it too is imperfect against 
b2bua
grinders.

Which all rather begs the question of what problems for what audience
we're really solving for. If it's for reputation people, I'm not sure that
P-A-I signed/unsigned makes a big difference. Of course it's no secret
that I think that lipstick on the tel: uri pig is pretty useless, so I'm 
struggling
if there's anything more here than trying to slay the unslayable.

       Mike

---

From: Adam Roach <[email-masked]>
Date: Tue, 08 Jul 2008 17:40:50 -0500

> 2) 4474 signs things which many real-world cases will break the signature of, and thus has a deployment problem (whether that's fixable, or by design, is another topic of debate).  But that's anoth…

In theory, you're talking about To, From, Call-ID, CSeq, Date, Contact, 
and the request body. Proxies aren't allowed to change those (with the 
exception of To and From, which are done only in the context of 4474 and 
RFC 4916), and user agents set them before the 4474 signature goes on them.

In practice, the elephant in your elephant (or small hairy predator) is 
the body. You're talking about SBCs, and the thing that SBCs want to 
change that breaks RFC 4474 is the body. And that was kind of a 
necessary hack back before user agents did much in the way of NAT and 
firewall traversal. But any real, commercial user agent I've played with 
in the past five years or so has at least rudimentary support in this 
area, such that body tweaking is mostly unnecessary.

In other words: there's a better solution than body mangling, and it's 
supported by most modern SIP clients. Let's not gut 4474 to maintain our 
older, broken network architectures.

/a

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 Jul 2008 16:13:32 -0700

> Behalf Of Adam Roach
> Sent: Tuesday, July 08, 2008 3:41 PM
> To: Hadriel Kaplan
> Cc: [email-masked]; Michael Thomas
> Subject: Re: [Sip] Signing P-Asserted-Identity
> 
> > 2) 4474 signs things which many real-world cases will break 
> the signature of, and thus has a deployment problem (whether 
> that's fixable, or by design, is another topic of debate).  
> But that's another elephant in the room, or maybe a lion, 
> smaller but hairy.
> >   
> 

Hadriel tried to carefully explain why SBCs change the body in 
draft-kaplan-sip-uris-change-00.txt.  It isn't because of NAT.

Please read draft-kaplan-sip-uris-change-00.txt.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 Jul 2008 16:17:09 -0700

...
> not _really_ a fault of 4474 per se, it's that you're hoping 
> essentially for the impossible: having a signature survive through 
> a b2bua sausage factory.
>
> Sounds all too familiar.

It sounds familiar because email has similar problem.

SIP's B2BUA 'sausage factory' is akin to email's mailing list 'sausage
factory'.  DKIM managed to engineer a solution to email's mailing list
sausage factory, yes?  

There are now three proposals to engineer a solution to SIP's B2BUA
'sausage factory':  draft-wing-sip-identity-media, 
draft-fischer-sip-e2e-sec-media, and 
draft-kaplan-sip-asserter-identity.

The worthwhile first problem is not reputation, but just a usable 
white-list.  Whitelists without cryptographic identity are only good 
until spammers successfully guess or successfully determine what 
identities are on your whitelist.  With only 10 billion E.164 
numbers in the +1 country code, it shouldn't take them nearly as 
long as it did for spammers to start guessing email whitelists.

(I have a whitelist for [email-masked], but only if it came via
one of Amazon's mailers.  This is because spammers learned that
many people, such as me, had such a whitelist.  Criminals that,
today, send email that looks like it came from my bank are likely,
tomorrow, to initiate VoIP calls with an E.164s that belong to
my bank.  I would like to have cryptographic identity standardized
when that happens so that we do not incur an additional two year
delay in getting it standardized and then another year delay to
get it into products.)

-d

> I agree with the "blame me" stance, and I'm
> > There has not been any uptake of 4474 for a bunch of 
> reasons, not the least of which is there's no problem yet, 
> and for some/many cases we know it won't work.  I have no 
> doubt a PASS signature is not the be-all-end-all solution.  
> But I do know it takes years to get something spec'ed, 
> implemented, tested, and deployed in any scale that will 
> matter.  So I'm trying to do a short-cut, instead of waiting 
> for a problem: thus, an informational P-header.
> >

---

From: Michael Thomas <[email-masked]>
Date: Tue, 08 Jul 2008 16:38:22 -0700

> factory'.  DKIM managed to engineer a solution to email's mailing list

In  a general way? No not really. If you have any way to make SIP
play better with manglers in a systematic way, I'd seriously consider
it. DKIM didn't have that luxury, or more specifically we didn't think
anything that tried to get the installed base to do anything other than 
add a
signature header somewhere in the pipeline was feasible. B2BUA's
(etc) are still relatively new critters so you might have say about what
constitutes a "well behaved B2BUA".
> delay in getting it standardized and then another year delay to

I'm sorry, but whitelisting your bank's e.164 seems wacky, Dan. I have
no clue what my bank's e.164 is. Why exactly do I want to perpetuate
my clueless about their numbers into the future with super-signed but
still unrecognizable identifiers? Even with my cell phone it doesn't annoy
me with the e.164 of anybody I'd whitelist; it tells me their name.

I swear that there's something really circular going on here, but I'm just
too dull witted to figure it out.

       Mike
>>>> Waiting-and-seeing what the reputation folks actually need 
>>>>         
>> versus guessing
>>     
>>>> I'm guessing that lack of coverage of P-A-I is not one of 
>>>>         
>> the reasons.
>>

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 Jul 2008 16:58:05 -0700

> Sent: Tuesday, July 08, 2008 4:38 PM
> To: Dan Wing
> Cc: 'Hadriel Kaplan'; [email-masked]
> (etc) are still relatively new critters so you might have say 
> about what constitutes a "well behaved B2BUA".

SBCs and many B2BUAs modify the SIP bodies that contain SDP, and that is not
changable or avoidable.  See draft-kaplan-sip-uris-change-00.txt for why.

> still unrecognizable identifiers? Even with my cell phone it 
> doesn't annoy me with the e.164 of anybody I'd whitelist; it tells 
> me their name.

Many cellular phones (and some standalone caller-id boxes) will
substitute the incoming E.164 with a name that matches the
addressbook.  That is what my cellular phone does.  I don't know
if your cellular phone does that, or if your cellular phone is 
displaying the name provided by the PSTN.

I'm sorry that you do not have the number of your bank in your
phone.  Please substitute another institution or person, which
you do have in your phone, and for which you would answer the
phone.  I, personally, do not know the number of my bank, either.
It was merely an example of unauthenticated identity and how
a spammer or a criminal can take advantage of unauthenticated
identity; sorry you took it literally.

> I swear that there's something really circular going on here, 
> but I'm just too dull witted to figure it out.

Yeah, you have completed several years working on identity
for email, but you are telling the SIP community that SIP 
doesn't need identity for SIP.  From my perspective that is circular 
reasoning.

-d

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 8 Jul 2008 20:47:32 -0400

> From: Adam Roach [mailto:[email-masked]]
>
> change that breaks RFC 4474 is the body.

Actually, lots of things change the To and From.  If you built a "proxy" that can't be configured to change 'em, you're probably not in business long.  Of course you're not a 3261 proxy at that point, but more of a b2bua.  Heck, lots of things change Call-id and Cseq and Contact, too.  You're talking like the whole mammal class that changes at least one of those To/From/Call-id/Cseq/Contact things, not just elephants.

> And that was kind of a

It's really not a secret that SBC's change SDP for a whole bunch of reasons that have nothing to do with NATs.  And the list of reasons is actually growing, sadly, not getting smaller.  But that's not the point.  Sign SDP if you feel you need to.  Don't sign something you don't feel you need to.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 8 Jul 2008 21:00:59 -0400

> for the impossible: having a signature survive through a b2bua sausage

Right, nothing is really the fault of 4474 - just like nothing about S/MIME or AIB is really their fault either.  Useful at all though, they are not.
I don't disagree though that it's a sausage factory and it'll be a bit of rolling the dice to see if this thing works or has value.

> the impossible and the unknown.

Yup.  It sucketh.

> A short cut! Run away! :)

When the hair is long and the temperature hot, a short-cut is sometimes what you really need. :)

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Tue, 08 Jul 2008 22:08:57 -0500

> Please read draft-kaplan-sip-uris-change-00.txt.

Yikes. That's not a circus -- that's a abattoir. It's a very careful 
analysis of why carriers want all of SIP except for the SIP part.

It looks like it boils down to:

    4.1.1(a) - Some SIP products are broken by either design or
    implementation

    4.1.1(b) - Inter-service provider federation is being rolled out
    without any of the tools the IETF has defined for that kind of thing

    4.2 - Service providers won't deploy DNS, despite it being integral
    to SIP and the Internet at large

    4.3 - (Mostly a symptom of 4.2) People are deploying security
    theater without any of the tools the IETF has defined for that kind
    of thing, and tel: URLs aren't apparently supported, even when E.164
    is the only useful identifier in use. (If you can change the domain
    of a URI and still have it mean anything at all, it should have been
    a tel: URL anyway)

    4.4 - This isn't a stand-alone issue; it's a symptom of 4.1.1(b)

In short -- if we ignore the software bugs, it looks like the problems 
all boil down the service providers choosing to ignore various 
IETF-defined solutions (mostly as they relate to security). Why do we 
think we can come up with a new security mechanism in the IETF and have 
it make half a whit of difference to organizations who are clearly 
hostile to IETF-developed security mechanisms?

/a

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Jul 2008 08:31:32 -0700

> In short -- if we ignore the software bugs, it looks like the 
> problems all boil down the service providers choosing to ignore 
> various IETF-defined solutions (mostly as they relate to security).

By IETF-defined security solutions, are you referring to Speermint, 
which is all about SBE and DBEs?  Speermint has not created an RFC
yet.  Hadriel's document explains in detail what he has seen 
in existing, real-world deployments.  I agree the reality is
depressing.  I have thrown up my hands many times, too.

> Why do we think we can come up with a new security mechanism 
> in the IETF and have it make half a whit of difference to 
> organizations who are clearly hostile to IETF-developed 
> security mechanisms?

By developing protocols that meet their needs and work in their
networks -- the same as every protocol that someone will use.  Right
now, 4474 doesn't work.  Right now, service providers are abusing
P-A-I in a way we know will cause harm.  We could sit back and let
them figure out a solution.  Or we could step up and define the
best solution that meets their needs and works in their networks,
and which works best with the academic view of SIP.

There are similarities between the 'Service Providers are 
destroying SIP' argument and the 'NATs are destroying the 
end-to-end Internet' arguments popular in the IETF during the 
1990's.  NATs were (and are) deployed because they met a need.  
The abuse of SIP is being done to meet a need -- it is not being 
done to upset the digerati.

-d

---

From: Adam Roach <[email-masked]>
Date: Wed, 09 Jul 2008 11:04:57 -0500

On 7/9/08 10:31 AM, Dan Wing wrote:
> which is all about SBE and DBEs?

No; I mean solutions like mutual TLS for domain authentication. Or even 
IPSec gateways, like 3GPP has defined. There are secure ways to do what 
service providers want to do. But, for some reason, the idea that you 
can secure networks by whitelisting based on unverified "From" header 
fields has gained mindshare. For some reason, people are still 
authenticating based on source IP address (!!!) instead of using any of 
a myriad of certificate-based techniques. I mean solutions like RFC 3263 
for machine location instead of using point 
codes^H^H^H^H^H^H^H^H^H^H^HIP addresses.

...
> done to upset the digerati.

I don't think the situations are fully comparable. I understand the 
problems NATs were introduced to solve. You'd have a hard time finding 
anyone in the IETF who doesn't operate at least one NAT of their own. 
It's a sad little secret that we hate them from a protocol design 
perspective, but embrace them for our day-to-day tasks.

Stupid security, on the other hand, isn't something you'll find anyone 
who knows the first thing about computers doing. No one uses stock FTP 
or telnet for real tasks any more -- it's all scp and ssh. But ITSPs 
don't deploy SIP over TLS for reasons I can't fathom. Anyone who knows 
the first thing about IP networks recognizes that it is laughable to 
authenticate based on source IP address. And yet ITSPs insist on doing 
so. The most popular application on the internet has a well-exercised, 
certificate-based, crypto-secure means of determining the identity of a 
server (TLS). SIP, from its inception, has been able to leverage this 
exact mechanism at least for authentication of servers and for 
confidentiality of signaling. ITSPs aren't deploying it.

The problem isn't a lack of available solutions for these kinds of 
problems -- it's the fact the ITSPs are employing the same kind of 
moronic "security" that gave rise to blue-boxing in the 1970s. I don't 
claim that it's being done to upset us; the reasons aren't exactly 
clear. They could be ignorance. The could be intransigence. They could 
be plain stupidity. But there's something there that's preventing the 
adoption of any real IETF-defined security by ITSPs.

Given that as a backdrop, I don't see how our defining Yet Another 
Security Mechanism is going to make one whit of difference. ITSPs aren't 
deploying the stuff we've already done, even the stuff that is 
completely ready for prime time and doesn't get in the way of any 
business needs. How will this effort be different?

/a

---

From: Michael Thomas <[email-masked]>
Date: Wed, 09 Jul 2008 10:49:52 -0700

Adam Roach wrote:
> certificate-based, crypto-secure means of determining the identity of 
> a server (TLS). SIP, from its inception, has been able to leverage 
> this exact mechanism at least for authentication of servers and for 

Maybe it's the certificates. If ssh required certs to operate, do you 
think it
would have the massive uptake that it's seen? I don't.

          Mike

---

From: Adam Roach <[email-masked]>
Date: Wed, 09 Jul 2008 12:51:52 -0500

On 7/9/08 12:49 PM, Michael Thomas wrote:
> Adam Roach wrote:
>> Stupid security, on the other hand, isn't something you'll find 
>> anyone who knows the first thing about computers doing. No one uses 
>> stock FTP or telnet for real tasks any more -- it's all scp and ssh. 
>> But ITSPs don't deploy SIP over TLS for reasons I can't fathom. 
>> Anyone who knows the first thing about IP networks recognizes that it 
>> is laughable to authenticate based on source IP address. And yet 
>> ITSPs insist on doing so. The most popular application on the 
>> internet has a well-exercised, certificate-based, crypto-secure means 
>> of determining the identity of a server (TLS). SIP, from its 
>> inception, has been able to leverage this exact mechanism at least 
>> for authentication of servers and for confidentiality of signaling. 
>> ITSPs aren't deploying it.
>

https?

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Jul 2008 14:10:59 -0400

Well,

ssh without certs requires that I share a secret with each destination I 
want to connect to. That isn't going to fly for phones.

And while https doesn't require the client to have a cert, it still 
requires the server to have one. So that isn't going to fly (for e2e) 
either.

And as soon as you say "well, maybe it doesn't have to be e2e" then you 
end up back where we are.

	Paul

---

From: Adam Roach <[email-masked]>
Date: Wed, 09 Jul 2008 13:20:58 -0500

On 7/9/08 1:10 PM, Paul Kyzivat wrote:
> Well,
>
> ssh without certs requires that I share a secret with each destination 
> I want to connect to. That isn't going to fly for phones.
>
> And as soon as you say "well, maybe it doesn't have to be e2e" then 
> you end up back where we are.

You're completely missing my point.

We, the IETF, have developed various security mechanisms with varying 
properties and different levels of complexity.

Even the dirt-simple, well-deployed, proven ones -- like server 
authentication and hop-by-hop confidentiality -- are being ignored by 
the ITSPs.

If they're ignoring the no-brainers, why do we think they'll pay 
attention to anything with even a slight bit of complexity (like signing 
P-Asserted-Identity)?

/a

---

From: Michael Thomas <[email-masked]>
Date: Wed, 09 Jul 2008 11:25:50 -0700

Adam Roach wrote:
> attention to anything with even a slight bit of complexity (like 
> signing P-Asserted-Identity)?
Do you think that those same ITSP's are still using FTP and Telnet?

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 09 Jul 2008 11:27:16 -0700

> I want to connect to. That isn't going to fly for phones.

Not true, or at least misleading. Anything you can do with a cert, you can
do with raw keys too which shouldn't be surprising since certs are just a
particular manifestation of a key/name binding mechanism.

SSH is a real life example of a mutually authenticated e2e crypto scheme
that basically just appeared at out nowhere to quickly rid ourselves of
ftp and rsh. The fact that IETF keeps ignoring why SSH works and
nothing else does remains a serious problem.

Key centric, leap of faith, and "good enough" manifestly work in real
life. Everything else is suspect.

          Mike
>>>> stock FTP or telnet for real tasks any more -- it's all scp and 
>>>> ssh. But ITSPs don't deploy SIP over TLS for reasons I can't 
>>>> fathom. Anyone who knows the first thing about IP networks 
>>>> recognizes that it is laughable to authenticate based on source IP 
>>>> address. And yet ITSPs insist on doing so. The most popular 
>>>> application on the internet has a well-exercised, 
>>>> certificate-based, crypto-secure means of determining the identity 
>>>> of a server (TLS). SIP, from its inception, has been able to 
>>>> leverage this exact mechanism at least for authentication of 
>>>> servers and for confidentiality of signaling. ITSPs aren't 
>>>> deploying it.
>>>
>>> Maybe it's the certificates. If ssh required certs to operate, do 
>>> you think it

---

From: Adam Roach <[email-masked]>
Date: Wed, 09 Jul 2008 13:32:19 -0500

> Do you think that those same ITSP's are still using FTP and Telnet?

I don't have enough visibility into ITSPs' operations infrasture to 
register an informed opinion. I wouldn't be surprised, if the same guys 
design their operations infrastructure as do their SIP infrastructure.

I'm not sure how this point plays into the conversation, though -- these 
same organizations all have a valid HTTPS certificate they use for their 
web site.

/a

---

From: Dan York <[email-masked]>
Date: Wed, 9 Jul 2008 14:54:07 -0400

> stock FTP or telnet for real tasks any more -- it's all scp and ssh.

(Reading this as I just finish FTP'ing files up to a web hosting  
provider.)    Sadly, I think there's still a great amount of FTP  
floating around.  Thankfully, though, I'm seeing very little telnet  
left.

> Anyone who knows the first thing about IP networks recognizes that  
> it is laughable to authenticate based on source IP address. And yet  
> internet has a well-exercised, certificate-based, crypto-secure  
> means of determining the identity of a server (TLS). SIP, from its  

(Tossing on my VoIP Security Alliance (VOIPSA) hat)  So over the past  
couple of years I have been asking this exact question of ITSPs with  
whom I talk - why aren't you using TLS-encrypted SIP.  The answers  
almost always come down to:

1. Performance.  "TLS-encrypted SIP is great in theory but when you  
are terminating 10,000 simultaneous SIP connections there is too much  
overhead."  (My typical response: Can't you get hardware SSL  
accelerators?  Or, gee, giant websites can do SSL for HTTP, are SIP  
connections really that much different?)

2. Ignorance of the security issue. "Well, it's all running mostly  
over my own network? What's the real exposure?" (My response - point  
them to http://www.voipsa.org/Resources/tools.php )

3. Laziness.  "None of our customers are asking for it!"  (My  
response: "Because they don't realize it's an issue and are trusting  
in you to keep them safe. They think it is like the carrier-controlled  
walled world of the PSTN.")

4. Ignorance of the state of the standards/technology. "Well, the IETF  
is still defining all of that."  (My response is to point out that  
media encryption and SRTP key exchange may be still evolving but TLS/ 
SIP is well understood.)

5. Cycles/Staff, aka "We'll get around to it".  With especially  
smaller ITSPs, I often get an answer of something like "it's on our  
roadmap but we just haven't yet gotten around to it".  With limited  
staff and cycles, they say (understandably) their first issue is  
making the system work... and then they'll worry about securing it...  
some day... if they make money... if they hire more staff... then  
maybe they'll get around to it.   (My response - throw up hands in  
dismay and go search for a beer.)

The performance argument, especially, is one I have heard repeatedly  
for TLS-encrypted SIP.  I certainly do understand that there *is* some  
degree of a performance hit, but in this era of high-volume and high- 
performance SSL-encrypted web sites I find it odd that we can't  
leverage that technology into TLS-encrypting SIP sessions.

I think, sadly, that ultimately it will take some kind of "significant  
event" where there is a significant information loss or denial of  
service for customers to start asking ITSPs for it.  Either that or  
perhaps some legislation around privacy or something like that.

> Security Mechanism is going to make one whit of difference. ITSPs  
> aren't deploying the stuff we've already done, even the stuff that  
> is completely ready for prime time and doesn't get in the way of any  
> business needs.

In my somewhat jaded opinion, ITSPs are going to deploy "the stuff  
we've already done" related to SIP security when either:

1. It makes them money.

2. It saves them money. (Really a variant of #1.)

3. It reduces their "risk" in a way they can quantify. (A variant of  
#2.)

4. It becomes a market requirement (variant of #1), potentially  
because either:
      a) a market leader adopts it and the ITSPs start losing sales  
for lack of it; or
      b) some event happens where they need to for PR/marketing  
purposes.

5. It becomes a differentiator in the market place for them to compete  
against larger competitors. (Variant of #1, and something I've seen  
from a few smaller ITSPs ("We're your source for secure SIP  
connections."))

6. It becomes a requirement based on government compliance legislation  
or other industry compliance requirements (variant of #1).  (Tip: Get  
VISA/MasterCard to throw SSL-encrypted SIP into the next iteration of  
the Payment Card Industry (PCI) Data Security Standard (DSS) and you'd  
wind up with rapid deployment.  You can't connect to the VISA/MC  
network if your networks don't meet PCI-DSS.  If you can't connect,  
you can't take credit cards... and we're back to #1.)

My 2 cents,
Dan

---

From: Dan York <[email-masked]>
Date: Wed, 9 Jul 2008 15:18:24 -0400

Adam,

> business needs. How will this effort be different?

I don't know that signing P-A-I is necessarily the answer, but in my  
opinion there are perhaps two reasons why ITSPs might be inclined to  
adopt some form of authenticated identity that we arrive at:

1. PERCEPTION VS. THE PSTN - There's a whole lot of ITSPs out there  
who would like to get your "SIP trunk" business and ultimately would  
like to build their own federated SIP networks to bypass the PSTN  
entirely.  So if you're going to do that, you have to be "at least as  
good" as the PSTN.  Right now, the majority of folks out there have a]  
belief in the integrity of PSTN identity / "Caller ID".  We all on  
this list may understand how easy that identity is to spoof... but the  
majority of folks out there do not.  So if I'm an ITSP building a SIP  
infrastructure and I want people to come to my system, I would think  
that ITSP would not want telemarketers masquerading as other numbers  
on a large scale.... this could lead to customers saying "Hmmm... we  
didn't have these problems with the old system."  I would *think*, but  
certainly could be wrong, that preventing this would be of interest.   
(A savvy ITSP could even turn it into a marketing feature in that they  
provide *better* identity security than the PSTN.)

2. GOVERNMENT COMPLIANCE - As an example, the US Congress continues to  
work on Caller ID-related legislation, the latest being last year's  
"Truth in Caller ID Act of 2007" which passed the US House and then  
floundered in the Senate:
   http://www.govtrack.us/congress/bill.xpd?bill=h110-251
   http://www.govtrack.us/congress/bill.xpd?bill=s110-704
   http://www.opencongress.org/bill/110-s704/show

This bill "amends the Communications Act of 1934 to make it unlawful  
for any person in the United States, in connection with any  
telecommunications service or Internet protocol (IP)-enabled voice  
service, to cause any caller identification (ID) service to knowingly  
transmit misleading or inaccurate caller ID information with the  
intent to defraud, cause harm, or wrongfully obtain anything of  
value..."

I'd imagine that sooner or later something like this will pass in the  
US (especially if there is a public case of identity theft linked to  
spoofed Caller ID) and somewhere in there it may fall to ITSPs to  
prove that they were not the ones altering identity information.

Obviously the IETF is a global organization and so it can't  
necessarily care what the US gov't does... but I'm sure other  
governments will pass similar legislation (if they haven't already).   
At some point I think the ITSPs will have to care a bit more about the  
identity of who is on their network.  If there is an open standards- 
based solution, they'll look at that... if not, they'll look at  
proprietary solutions.

Then again, I could be completely wrong about all this. The warranty  
expired long ago on my crystal ball.

My 2 cents,
Dan

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 09 Jul 2008 21:30:30 +0200

Adam Roach wrote:
>> 2) 4474 signs things which many real-world cases will break the 
>> signature of, and thus has a deployment problem (whether that's 
>> fixable, or by design, is another topic of debate).  But that's 
>> another elephant in the room, or maybe a lion, smaller but hairy.
>>   
> 

Can you send me a link to such a client?

-jiri

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 09 Jul 2008 14:33:09 -0500

> connections really that much different?)

Yes, a bit.  For one, HTTPS works fine as long as the server has
a certificate.  SIP can do so as well, but for TLS connections
between two proxies, both of which have certificates, the mutual
authentication problem is rather new in SIP.  Second, the
temporal nature of a TLS connection is different in SIP than
in HTTPS.  In the latter, clients typically establish many
simultaneous connections to pipeline downloads and then promptly
close them (unless keep-alive is negotiated.  Even if keep-alive
is negotiated, the life of a HTTP transaction is shorter than a
SIP transaction, so closing the TLS connection is a perfectly
good thing to do when a client is done accessing the resource
in HTTPS.)  Third, the whole notion of upgrading/downgrading
URIs does not exist in HTTP, so when you see a https:// scheme,
you know that it is TLS from client to origin server, even in the
presence of HTTP proxies.  Fourth, even in the presence of HTTP
proxies, the certificate displayed to the client is that of the
origin server, which is not the case in SIP's hop-by-hop TLS model,
which has lead to its own set of problems amply documented else-
where.  And finally, in HTTP there is only one transport: TCP.
So TLS-over-TCP accelerators became commodity items.  In SIP, with
the multiple transports to support and the fact that TLS can run
on top of all of them makes it hard to get accelerators that
support multiple transports (maybe EKR or someone else can correct
me here, but I don't think there are dtls accelerators in use
today -- I am not sure whether a TLS-over-TCP accelerator's firm-
ware can be used to support TLS-over-UDP without any modifications.
Even OpenSSL had to be modified to support dtls at the TLS record
layer, so I would assume that any existing TLS accelerator would
have to be so retrofitted.)

 > 4. Ignorance of the state of the standards/technology. "Well, the
 > IETF is still defining all of that."  (My response is to point out
 > that media encryption and SRTP key exchange may be still evolving but
 > TLS/SIP is well understood.)

Media encryption and SRTP key exchange have stabilized of late, as
have some TLS-specific concerns in SIP through various drafts
like sip-sips and domain-certs, sec-flows, etc.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs
_______________________________________________
Sip mailing list  https://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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Jul 2008 10:16:32 -0400

inline:

> analysis of why carriers want all of SIP except for the SIP part.

Sadly, many of these issues exist within enterprise too Adam. SDP gets 
rewritten there all the time and its almost never for NAT traversal 
reasons. Most of them boil down to practical issues that arise from the 
nature of those networks. Examples include transcoding to deal with low 
bandwidth WAN links and 2833 detection to deal with H323 endpoints that 
don't support it.

> hostile to IETF-developed security mechanisms?

I'm pretty sure its not malice at work here. Rather, I think its that, 
there are lots of practical issues that got in the way of deploying SIP 
in the 'pure' way it was originally envisioned. I have no doubt that 
folks with working SIP networks would welcome a security solution that 
improves upon the current situation and is actually deployable. So the 
choice we have to make is - do we continue to produce specifications 
that ignore SIP as it is deployed, guaranteeing that these documents are 
of academic interest only, or do we consider "works with actual 
deployments" as a legitimate engineering constraint?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Jul 2008 10:30:00 -0400

inline:

Hadriel Kaplan wrote:
> 
>> -----Original Message----- From: Elwell, John
>> [mailto:[email-masked]]
>> 
>> referenced in section 1.1 of your draft. If a request or response
>> passes through two or more trust domains, the UA will receive only
>> the assertion from the nearest trust domain. Also the P-Original-To
>> header field will not necessarily contain the original To value.
> 
> PASS is intended to only address such issues in specific deployment
> scenarios, just as PAI is.  I don't think I said PASS was end-to-end
> in all scenarios - just for a given trust-domain, and yes the scope
> of PAI and PASS is tied.  The main scenario for its use would be one
> of a single trust-domain, including one where there are stub
> nodes/domains attached to that trust-domain but are not technically
> in it, and are not transits themselves.

If you are accepting the notion of trust domain defined in 3324 and used 
by 3325, then I think PASS doesn't provide any additional value. If we 
do indeed all mutually trust each other, then why do I need to 
cryptographically verify the asserter?

I would argue that your draft is really trying to make PAI work in a 
different type of 'trust domain' - one in which there are some folks 
that I trust a lot less. So if I have:

stub1 - SP1 - SP2 - stub2

with stub1 and stub2 being enterprises which insert their own PAI, your 
  draft would allow stub2 to determine that it was indeed stub1 who 
inserted the PAI, and stub2 can utilize reputation systems or 
whitelists/blacklists to deal with ones that misbehave.

Indeed, I'd go so far as to say that, your draft is trying to add 
cryptographic assertions to PAI so that it has some possibility of being 
used on the Internet and in topologies that don't fit the trust domain 
definition of RFC3324/5, and in that sense it really is an alternative 
to RFC4474.

What I think is missing from your draft is a clear discussion of what 
attacks are possible in RFC3325 which are now prevented here. Barring a 
reputation system or whitelist of asserters, I wasn't clear there were 
any. Would you agree?

Thanks,
Jonathan R.

---

From: Adam Roach <[email-masked]>
Date: Wed, 09 Jul 2008 15:46:08 -0500

On 7/9/08 2:30 PM, Jiri Kuthan wrote:

Adam
Roach wrote:

...

In practice, the elephant in your elephant (or small hairy predator) is
the body. You're talking about SBCs, and the thing that SBCs want to
change that breaks RFC 4474 is the body. And that was kind of a
necessary hack back before user agents did much in the way of NAT and
firewall traversal. But any real, commercial user agent I've played
with in the past five years or so has at least rudimentary support in
this area, such that body tweaking is mostly unnecessary.

In other words: there's a better solution than body mangling, and it's
supported by most modern SIP clients. Let's not gut 4474 to maintain
our older, broken network architectures.

Here are a couple that are both pretty old (one soft, one hard). I
didn't have to go hunting for these; they're just the softphone I have
installed on this machine and the hard phone I have on my desk.

http://www.counterpath.com/x-lite.html&active=4

http://www.snom.com/en/snom360_voip_phone0.html

/a

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Jul 2008 14:19:15 -0700

> codes^H^H^H^H^H^H^H^H^H^H^HIP addresses.

They are not using them because they do not see the benefit of
them.  The same can be said of ENUM and TRIP, which ITSPs are
either ignoring or 'misusing' (from an IETF perspective).  The
avoidance of RFCs is not at all unique to ITSPs.

But it doesn't matter what the ITSPs do inside their networks -
we can do this without the ITSP needing to do per-transaction
crypto, or TLS, or squat.  If it causes them no harm, causes
them no grief, and lets them continue Business As Usual, it's
a win for them and a win for the edge (their subscribers).

We can provide edge-to-edge identity (between enterprises, or 
handset-to-handset) in both worlds:  the world that exists (which 
has ITSPs with B2BUAs and SBCs) and the world that we hope will
exist (RFC3263 routing on the Internet, perhaps with some
peer-to-peer sprinkled on top).  SIP's current identity mechanism,
RFC4474+RFC4916, only works with the latter.

I want an identity mechanism that works with both.  And I have
long been convinced it is possible to build such a beast.

-d

---

From: Adam Roach <[email-masked]>
Date: Wed, 09 Jul 2008 16:24:44 -0500

On 7/9/08 9:16 AM, Jonathan Rosenberg wrote:
> there are lots of practical issues that got in the way of deploying 
> SIP in the 'pure' way it was originally envisioned. I have no doubt 
> that folks with working SIP networks would welcome a security solution 
> that improves upon the current situation and is actually deployable. 
> So the choice we have to make is - do we continue to produce 
> specifications that ignore SIP as it is deployed, guaranteeing that 
> these documents are of academic interest only, or do we consider 
> "works with actual deployments" as a legitimate engineering constraint?

My point is that we *do* have security mechanisms that are *deployable*, 
like TLS. Not mutually-authenticated-TLS (which is not very widely 
deployed in any protocol), but the normal TLS that _pervades_ the WWW. 
Vijay points out a handful of reasons why these approaches are not 
perfect from a security perspective, but they're certainly an 
improvement over having no security.

So, why aren't *they* deployed?

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 09 Jul 2008 16:36:07 -0500

> long been convinced it is possible to build such a beast.

But *who* is going to deploy it?

/a

---

From: Michael Thomas <[email-masked]>
Date: Wed, 09 Jul 2008 14:38:26 -0700

Adam Roach wrote:
>> I'm pretty sure its not malice at work here. Rather, I think its 
>> that, there are lots of practical issues that got in the way of 
>> deploying SIP in the 'pure' way it was originally envisioned. I have 
>> no doubt that folks with working SIP networks would welcome a 
>> security solution that improves upon the current situation and is 
>> actually deployable. So the choice we have to make is - do we 
>> continue to produce specifications that ignore SIP as it is deployed, 
>> guaranteeing that these documents are of academic interest only, or 
>> do we consider "works with actual deployments" as a legitimate 
>> engineering constraint?
>
> My point is that we *do* have security mechanisms that are 
> *deployable*, like TLS. Not mutually-authenticated-TLS (which is not 
> very widely deployed in any protocol), but the normal TLS that 
> _pervades_ the WWW. Vijay points out a handful of reasons why these 
> approaches are not perfect from a security perspective, but they're 
> certainly an improvement over having no security.
>
TLS isn't very widely used on the net though. It's only used on as-needed
basis. SIP is probably not any different in that regard, and even worse
in some ways since there's not any one entity whose self interest is wrapped
up around "this needs to be safer". If you could convince banks, ecommerce,
etc users of SIP to only accept secured calls then you might get some uptake
just like the web, but until then...

          Mike

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Jul 2008 14:45:34 -0700

> But *who* is going to deploy it?

The very same entity that cares about identity:  the subscriber
connected to the ITSP, such as an enterprise connected to its
SIP trunking provider.

-d

---

From: Adam Roach <[email-masked]>
Date: Wed, 09 Jul 2008 16:54:27 -0500

> connected to the ITSP, such as an enterprise connected to its

Ah, so this argues for the media-path identity. I don't have as strong 
an opinion on that yet. My (possibly naive) first impression is that it 
has no better chance of surviving the SBC sausage factory any more than 
4474 does (given that SBCs tend to sit on the media path, too).

But this doesn't give any rationale for signing P-Asserted-Identity 
(which will need to be stripped off as it leaves the enterprise, 
rendering your use case pretty much moot).

/a

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Jul 2008 15:04:27 -0700

> Ah, so this argues for the media-path identity. I don't have 
> as strong an opinion on that yet. My (possibly naive) first 
> impression is that it has no better chance of surviving the SBC 
> sausage factory any more than 4474 does (given that SBCs tend to sit 
> on the media path, too).

Our views clearly differ on the survivability of 4474 identity through 
SBCs and the survivability of other identity techniques through SBCs.

I don't see how to reconcile those views, as there are ample I-D's
written by myself and others that attempt to explain how 4474 fails
and there are three other techniques that exist as individual drafts.

-d

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Jul 2008 18:04:53 -0400

Bringing this back to the original topic:

I did not think Hadriels draft was proposing that PAI get stripped at 
that boundary.

-Jonathan R.

---

From: Adam Roach <[email-masked]>
Date: Wed, 09 Jul 2008 17:08:25 -0500

> I did not think Hadriels draft was proposing that PAI get stripped at 

 From the abstract: "The use of these extensions is only applicable 
inside a set of administrative domains with previously agreed-upon 
policies for generation, transport and usage of such information."

This means that there's either an agreement with the ITSPs (which I'm 
arguing have demonstrably no interest in making this happen), or the 
information is stripped before handing to the ITSPs. Or am I missing 
something?

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 09 Jul 2008 17:10:18 -0500

> SBCs and the survivability of other identity techniques through SBCs.

I don't think *either* will make it through the networks that Hadriel 
cites in the draft you asked me to read.

/a

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Jul 2008 18:28:19 -0400

I had assumed enterprises would be part of the trust domain of the provider.

-Jonathan R.

---

From: Adam Roach <[email-masked]>
Date: Wed, 09 Jul 2008 17:30:11 -0500

> I had assumed enterprises would be part of the trust domain of the 

The crux of my argument is that the providers aren't playing along.

/a

>>> I did not think Hadriels draft was proposing that PAI get stripped 
>>> at that boundary.
>>

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 10 Jul 2008 11:56:27 +0200

If you are talking enterprise to some sort of public service provider
you will get both cases happening, and possibly on the same interface
between the two providers.

It may well be distinguished based on whether the traffic is public
network traffic or private network traffic, see the definitions in 

http://www.ietf.org/internet-drafts/draft-vanelburg-sipping-private-netw
ork-indication-01.txt
(revision expected shortly)

For public network traffic, the situation you are talking about has wide
acceptance for the PSTN in the US, but virtually no appearance in the
PSTNs of some European countries. When these operators go to IP, you can
expect the same approach to P-Asserted-Identity. 

For private network traffic, I would expect the trust domain to
encompass the enterprise and the public service provider for the support
of such a capability to make any sense, but there are still some awkward
public service providers out there.

Regards

Keith

> Behalf Of Jonathan Rosenberg
> Sent: Wednesday, July 09, 2008 11:28 PM
> To: Adam Roach
> Cc: [email-masked]; 'Michael Thomas'; Dan Wing
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 10 Jul 2008 09:36:11 -0400

> From: Jonathan Rosenberg [mailto:[email-masked]]
>

There're a couple points:
1) The trust-domain's transitive nature is brittle - we all know this, and the easy answer is "transitive trust doesn't work" or "that's the nature of transitive trust", but I think there are different levels of what one can and can't believe in for transitive trust - or at least I think providers have different concerns.  For example I don't think providers are very worried about MitM attacks, even in transitive trust domains.  (Or rather they worry about it in a different way)  And I don't think they're very worried about explicitly malicious providers in a transitive trust context.  But I do think they're worried about systems that are mis-configured or more open; or at least I think they will be when peering grows and gets more end-end SIP.

2) PAI's trust-domain is not fully transitive, in practice.  By that I mean some providers trust the PAI asserted by a peer, but not PAI's transited by that peer (PAI's asserted by domains beyond that peer).  Without some asserter identifier it's tricky to figure out the scope of the assertion trust domain.  In other words you could have providers A--B--C, and C trusts B's PAIs for calls originating at B, but not transiting through it.

One possible way to address those is with just a P-Asserter value, and not bother to sign it - under the rationale that if you're not worried about malicious behavior or MitM or whatever, an asserter identifier is sufficient to determine scope, and troubleshoot and such.  But I'm guessing that certain provider domains may be more believable by some folks based on their size or brand reputation, and that those high-profile providers would want to protect their brand from being used/abused by others.  But it's just a guess.

> definition of RFC3324/5, and in that sense it really is an alternative

Sort of, yes.  The idea for adding a P-Asserter id actually started before the idea of signing it - some of my customers were running into issues with PAI where troubleshooting it was painful in big peering arrangements (they weren't purposefully fraudulent, just wrong).  Then I was having an off-line discussion with some folks on this mailing list regarding 4474 Identity, and someone mentioned that PAI was very popular and that some providers will think PAI is good enough for identity.  So then we got into a discussion of why PAI will fail, and I suggested we just sign it, instead of From, and so yes that's the genesis of the draft.

But no I don't mean it for the "Internet", because it won't work right for all use cases/scenarios, and only applies for PAI.

> reputation system or whitelist of asserters, I wasn't clear there were

Yup.  I should add that in far more detail.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 10 Jul 2008 09:38:10 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam
> Roach
>

Well, it certainly has a "better" chance.  I mean we *know* 4474 won't survive *any* SBC, purely by definition of what an SBC does to be an SBC.  I *know* this draft will survive *some* deployed SBCs.  So it's a "better" chance.  How many it can survive across I don't know.  For example I do know of deployed SBC's even this PASS mechanism won't survive.  (and I'm not talking about particular vendors - I know some providers do modify the PAI)

I'm guessing it also has a better chance of surviving more b2bua's in general (not just SBC's) than 4474 would.

But there's no doubt it's a gamble.  I'm just trying to make the odds as good as possible while still having some payback.

> rendering your use case pretty much moot).

Huh?  It doesn't need to be stripped on leaving nor entering the Enterprise.  You lost me.

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Thu, 10 Jul 2008 15:13:35 -0500

> Huh?  It doesn't need to be stripped on leaving nor entering the 
Enterprise.  You lost me.

If that's not the intention, then I had mistaken the scope of 
applicability to imply that the asserter identity would be stripped upon 
leaving an administrative domain, unless the domain it was going to was 
part of a federation formed by specific business arrangements regarding 
identity.

Given that such isn't the case, the intention of the document is a bit 
clearer. I'm still queasy at adding additional ways to do the same 
thing, even if the properties are somewhat different. But if anyone else 
thinks that's important, I'll let them fight that battle.

/a

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 11 Jul 2008 08:56:47 +0100

Keith,

I understand that some service providers expect PAI to identify the
charged user, so accepting any PAI value outside the legitimate range of
the authenticated entity from which the request is received (e.g.,
authenticated at the IPSEC or TLS level) causes them grief. Hence,
considering an enterprise network to be part of their trust domain is
problematic for these service providers. In my opinion, the From URI is
more likely to pass through unchanged than the PAI. But perhaps the best
chance of success is to place the e2e-authenticated identity in some
other header field.

John

> Behalf Of DRAGE, Keith (Keith)
> Sent: 10 July 2008 10:56
> To: Jonathan Rosenberg; Adam Roach
> Cc: [email-masked]; Michael Thomas; Dan Wing

---

From: Adam Roach <[email-masked]>
Date: Fri, 11 Jul 2008 10:50:03 -0500

> chance of success is to place the e2e-authenticated identity in some

P-Original-From?

Actually, that would work pretty well -- if we add "P-Original-Call-Id," 
"P-Original-CSeq," "P-Original-Contact," and "P-Original-Identity," we 
could use RFC 4474 with just minor modification.

Or, even better, we could do away with P-Original-* headers altogether, 
and put the relevant header fields (including Identity) in an 
application/sipfrag body part. Then, you could use a normal RFC4474 
identity service, and add a security mangler to make the signature SBC-safe.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Jul 2008 12:52:09 -0400

Or, we could put the "original-From" in From, the "original-To" in To, etc.

	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 11 Jul 2008 17:51:41 +0100

Adam, 

> Sent: 11 July 2008 16:50
> To: Elwell, John
> Cc: DRAGE, Keith (Keith); Jonathan Rosenberg; [email-masked]; 
> Michael Thomas; Dan Wing
[JRE] I was thinking more of the proposal in the Fischer draft.

> could use RFC 4474 with just minor modification.
[JRE] It depends what we are trying to achieve. The Fischer draft is
aimed mainly at providing some authentication of the source of the
fingerprint of the certificate used to secure the media, rather than a
more general integrity protection of all these various bits of a SIP
request in general.

John

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 11 Jul 2008 17:52:48 +0100

Which would be ideal, if we were sure of getting them through service
providers unchanged.

John 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 11 July 2008 17:52
> To: Adam Roach
> Cc: Elwell, John; [email-masked]; Michael Thomas; DRAGE, Keith 
> (Keith); Dan Wing

---

From: Michael Thomas <[email-masked]>
Date: Fri, 11 Jul 2008 11:48:10 -0700

> Which would be ideal, if we were sure of getting them through service
Therein lies the conundrum with intermediate manglers like B2BUA's
and mailing lists managers, etc. On the one hand, you can sign very little
and be far more successful at surviving the mangler. However, that's buying
you very, very little since things that the manglers mangle are the very 
things
that you want to protect. So why bother.

An alternate approach is "you break it, you own it". That is, if you must
break the signature, all you can do is resign it and hope that your own
reputation is enough to convince the called party to accept the call. Yes,
this is messy and unsatisfying at many levels and leaves many unanswered
questions. But fundamentally what people are asking for here is impossible
if you insist on b2bua manglers.

Lastly, if you want e2e security the conversation needs to be... e2e. Be it
straight over the top of the internet, through a tunnel -- however you can
route opaque packets to and from the two ends -- that is the only way to
have any both security as well as robustness. If we'd just get over that,
our heads would eventually stop hurting from repeatedly bashing them
up against this brick wall.

       Mike

---

From: Adam Roach <[email-masked]>
Date: Fri, 11 Jul 2008 13:56:40 -0500

On 7/11/08 1:48 PM, Michael Thomas wrote:
> reputation is enough to convince the called party to accept the call.

Yes! I was trying to put together something explaining this, but never 
could make it concise enough. Your explanation is perfect.

The way to get identity through B2BUAs is to have them *be* back-to-back 
USER AGENTS. They demonstrate to a 4474 signer (which may be colocated 
with the B2BUA) that they are authentic agents of the signer's domain, 
authorized to assert the identity in the "From" header field, and all 
the 4474 goo can be added just fine.

/a

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 Jul 2008 11:58:21 -0700

> Elwell, John wrote:
> > Which would be ideal, if we were sure of getting them 
> > through service providers unchanged.
>
> and mailing lists managers, etc.

It is the conundrum for the entire Internet -- TCP 'protocol 
scrubbers' exist, TCP options get dropped, DSCP bits get changed,
ECN bits are mangled, and Router Alert Option gets dropped.

Such is the reality.  I wish it weren't the reality, too.

-d

> On the one hand, you can 
> sign very little

---

From: Michael Thomas <[email-masked]>
Date: Fri, 11 Jul 2008 12:23:16 -0700

> ECN bits are mangled, and Router Alert Option gets dropped.

Yet IPsec and TLS still work most of the time. Sticking a b2bua into
a stream is fundamentally different than routers and scrubbers, etc. Their
job is to change the very things you want to protect. Either you get to the
"break it/own it" or tunnel it across manglers. Anything else is eating
caking and having it to.

Has any one proposed tunneling SIP in SIP? Ie, the manglers get to
set up their rendezvous ("because they simply must") and then the
ends get to set up theirs? This is one way the real world routes around
damage too.

       Mike

---

From: Adam Roach <[email-masked]>
Date: Fri, 11 Jul 2008 14:25:27 -0500

> Such is the reality.  I wish it weren't the reality, too.

So... are groups within TSV proposing new extension header fields to 
carry things like "orginal diffserv codepoint" with the hope that TCP 
protocol scrubbers won't mess them up?

/a

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 Jul 2008 12:31:55 -0700

> ends get to set up theirs? This is one way the real world 

Yes, http://tools.ietf.org/html/draft-gurbani-sip-sipsec-01.  But
that only gives encrypted SIP signaling end-to-end -- it does not 
cause a firewall or SBC or B2BUA to open its permission for the
RTP flow.  A firewall or SBC will only open permissions for a 
flow it knows about: that is their primary purpose.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 Jul 2008 12:34:40 -0700

> protocol scrubbers won't mess them up?

http://tools.ietf.org/html/rfc3168#section-8

   This section considers the issues when a router is operating,
   possibly maliciously, to modify either of the bits in the ECN field.
   We note that in IPv4, the IP header is protected from bit errors by a
   header checksum;  this is not the case in IPv6.  Thus for IPv6 the
   ECN field can be accidentally modified by bit errors on links or in
   routers without being detected by an IP header checksum.

   By tampering with the bits in the ECN field, an adversary (or a
   broken router) could do one or more of the following: falsely report
   congestion, disable ECN-Capability for an individual packet, erase
   the ECN congestion indication, or falsely indicate ECN-Capability.
   Section 18 systematically examines the various cases by which the ECN
   field could be modified.  The important criterion considered in
   determining the consequences of such modifications is whether it is
   likely to lead to poorer behavior in any dimension (throughput,
   delay, fairness or functionality) than if a router were to drop a
   packet.
   ...

-d

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Jul 2008 17:14:16 -0400

Well, you could use SIP to establish a TLS "media session" e2e (using 
comedia). Then you could put another SIP session through it.

	Paul

---

From: Michael Thomas <[email-masked]>
Date: Fri, 11 Jul 2008 14:46:12 -0700

> flow it knows about: that is their primary purpose.
Ok, so we're already half way there. The other half is to use TCP or
whatever other means to get the media through. Sneer if you like, but
millions of skype users can't be wrong. If that's what it takes to route
around firewalls, then that's what it takes.  The fat lady has pretty much
sung on this security vs. new and kewl issue, and the firewall owners
have pretty much said that if you're willing to go through the TCP hoops
for media, we're willing to ignore that you're bypassing policy. Stupid,
I know, but that's manifestly what we have to work with.

          Mike

---

From: Adam Roach <[email-masked]>
Date: Sat, 12 Jul 2008 01:20:26 -0500

>    delay, fairness or functionality) than if a router were to drop a

Yes, the authors of RFC 3168 analyze what happens when a router is 
acting outside of specification, potentially with malice. But is TSV 
actively engaged in specifying how to duplicate information in a 
different part of the message in the hope that these non-conformant, 
potentially malicious intermediaries won't find it?

No, they aren't. Because that would be patently ridiculous. Recognizing 
the potential for an attack doesn't necessarily force the definition of 
comically[1] ill-conceived and easily defeated countermeasures.

Assume the draft on the table is published and implemented. How long 
before someone decides that their SBC "needs" to modify the 
"P-Original-To" header field? And when they do, will we just define 
another header field to squirrel away yet another copy of this 
information? (Should we go ahead and define "P-Original-P-Original-To" 
right now?)

/a

[1] I'm not using this word lightly -- when I presented the proposed 
solution of "signing P-Asserted-Identity" to a room full of engineers 
familiar with the SIP protocol, they broke out in spontaneous laughter. 
Without the frog-boiling that led us here as a working group, this idea 
is clearly humorous.
_______________________________________________
Sip mailing list  https://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: Hadriel Kaplan <[email-masked]>
Date: Sun, 13 Jul 2008 12:49:29 -0400

> information? (Should we go ahead and define "P-Original-P-Original-To"

This implies I'm trying to hide/tunnel the information from intermediaries to get around their policies.  I'm not.

SBC's (and others) modify the From/To URI for a bunch of reasons.  One of those reasons is relationship hiding, and for any such policy there is clearly no point in trying to avoid/bypass it, as they'll just go delete or modify any new headers as you point out.  There is nothing we can do for such cases, imho.

But for a lot of cases they're not modifying To/From for that reason - they're modifying it to either "fix" them for specific interop reasons, or to hide topology (ie, when it contains IP Addresses or hostnames).  Those are the cases I'm trying to get the information through.

-hadriel

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Sun, 13 Jul 2008 12:55:36 -0400

Hello,

There are times reality sucks..Hadriel is just giving you reality. 

Or better said, growing up my Irish born father told me many a times to
have some common sense and stop acting like a bloody American.

See you all in Dublin,

Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Sunday, July 13, 2008 12:49 PM
To: Adam Roach; Dan Wing
Cc: [email-masked]; 'DRAGE,Keith (Keith)'; 'Paul Kyzivat'; 'Michael
Thomas'; 'Elwell,John'
Subject: Re: [Sip] Signing P-Asserted-Identity

> information? (Should we go ahead and define "P-Original-P-Original-To"

This implies I'm trying to hide/tunnel the information from
intermediaries to get around their policies.  I'm not.

SBC's (and others) modify the From/To URI for a bunch of reasons.  One
of those reasons is relationship hiding, and for any such policy there
is clearly no point in trying to avoid/bypass it, as they'll just go
delete or modify any new headers as you point out.  There is nothing we
can do for such cases, imho.

But for a lot of cases they're not modifying To/From for that reason -
they're modifying it to either "fix" them for specific interop reasons,
or to hide topology (ie, when it contains IP Addresses or hostnames).
Those are the cases I'm trying to get the information through.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 13 Jul 2008 13:00:28 -0400

> the 4474 goo can be added just fine.

That would work if and only if the B2BUA owned a cert of the same domain as the From they changed it to.  That is actually not the case in practice, even when the From is an E.164.  It would also not work if the From was not an E.164, since they can't go changing sip:[email-masked] to sip:[email-masked], for example.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 13 Jul 2008 13:23:51 -0400

> Michael Thomas

So the question is: what is it that you really want to protect?  Is it literally the To/From/Call-id/etc. headers; or is it the source AoR, target AoR, and some additional info to prevent replay?

My belief is the latter.  Using the To/From/Call-id/etc. in 4474 was essentially a convenience, because the assumption was the info is already in those headers so one might as well reuse them for 4474's purpose.  But for some deployment scenarios those headers get changed - not because the changers *want* to hide the source/target AoR and anti-replay info, but for other reasons generally.  So I'm proposing creating specific headers to contain the same type of info.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Sun, 13 Jul 2008 12:55:35 -0500

On Jul 13, 2008, at 12:00 PM, Hadriel Kaplan wrote:

> That would work if and only if the B2BUA owned a cert of the same  
> domain as the From they changed it to.  That is actually not the  
> case in practice, even when the From is an E.164.  It would also not  
> work if the From was not an E.164, since they can't go changing sip:[email-masked] 
>  to sip:[email-masked], for example.

no, but garden.eden.com could  could sign an identity header with a  
From: of [email-masked].

Would a recipient trust it?  Why would you trust anything that was  
mangled by a B2BUA in the first place? If you trust the operator of  
the B2BUA, then trusting the re-signed identity seems just as  
reasonable. The good news is that this lets people who DON'T trust the  
operator of the re-signing B2BUA know that the call has been mangled.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 13 Jul 2008 14:05:51 -0400

> From: Dean Willis [mailto:[email-masked]]
>

Not according to 4474.  The cert domain and From domain must match.

-hadriel

---

From: Dan York <[email-masked]>
Date: Mon, 14 Jul 2008 08:02:37 -0400

On Jul 13, 2008, at 12:49 PM, Hadriel Kaplan wrote:

> But for a lot of cases they're not modifying To/From for that reason  
> - they're modifying it to either "fix" them for specific interop  
> reasons, or to hide topology (ie, when it contains IP Addresses or  
> hostnames).  Those are the cases I'm trying to get the information  
> through.

DY> Just to add to what Hadriel said, one of the additional arguments  
*for* an SBC that I've had given to me by different vendors at various  
shows is that they can "normalize" SIP and make SIP interoperability  
actually work between different vendors.  The SBC understands how  
exactly Vendor X speaks SIP and how exactly Vendor Y speaks SIP and  
can then enable the interconnection/interoperability.  So the reality  
is that there are SBCs out there that view as part of their function  
to "fix" SIP so that it can be interoperable.  In doing this "fixing",  
one can expect that the SBCs would be changing headers.

Regards,
Dan

---

From: Eric Burger <[email-masked]>
Date: Mon, 14 Jul 2008 11:56:24 -0400

[SIP Forum Chair Hat On]

This is a sad state of affairs, if we have to break SIP to make it  
work for broken implementations.

I can see this kind of work going on outside the IETF, but it seems  
out of place to hack Internet protocols willy-nilly to make them work  
for either non-Internet deployments or to interoperate with obsolete  
or broken implementations.

On Jul 14, 2008, at 8:02 AM, Dan York wrote:

>> But for a lot of cases they're not modifying To/From for that  
>> reason - they're modifying it to either "fix" them for specific  
>> interop reasons, or to hide topology (ie, when it contains IP  
>> Addresses or hostnames).  Those are the cases I'm trying to get the  
>> information through.
>
>
> DY> Just to add to what Hadriel said, one of the additional  
> arguments *for* an SBC that I've had given to me by different  
> vendors at various shows is that they can "normalize" SIP and make  
> SIP interoperability actually work between different vendors.  The  
> SBC understands how exactly Vendor X speaks SIP and how exactly  
> Vendor Y speaks SIP and can then enable the interconnection/ 
> interoperability.  So the reality is that there are SBCs out there  
> that view as part of their function to "fix" SIP so that it can be  
> interoperable.  In doing this "fixing", one can expect that the SBCs  
> would be changing headers.
>
> Regards,
> Dan
>
> --

---

From: Dean Willis <[email-masked]>
Date: Mon, 14 Jul 2008 11:24:38 -0500

> Not according to 4474.  The cert domain and From domain must match.

But that part COULD be changed, if one adequately described other  
acceptance rules. One could potentially  also "compound @" so we have  
an @nostrum defined in the context of @eden. Something like a signed  
uunet route.

---

From: Byron Campen <[email-masked]>
Date: Mon, 14 Jul 2008 11:32:51 -0500

> would be changing headers.

	I would say I don't know whether I should laugh or cry, but laughter  
is obviously much more fun. Seriously; how ridiculous do things need  
to get before we can no longer keep a straight face? (I gave up a  
while ago)

Best regards,
Byron Campen

---

From: Adam Roach <[email-masked]>
Date: Mon, 14 Jul 2008 14:08:23 -0500

> can do for such cases, imho.

At least, once they notice them, they'll delete or modify them. Until 
then, the identity stuff will quite possibly get through them just fine 
(potentially in violation of intended policy). But that's neither here 

> But for a lot of cases they're not modifying To/From for that reason - they're modifying it to either "fix" them for specific interop reasons, or to hide topology (ie, when it contains IP Addresses…

And they're doing this because some products have unilaterally taken the 
intended meaning of "To" and "From" and (intentionally or not) 
misinterpreted them.

Now, let's imagine a world in which we take on 
draft-kaplan-sip-asserter-identity as a working group item, and publish 
it as an RFC. Over then following several years, it sees a relatively 
high level of deployment. Are we to imagine that "P-Original-To" won't 
be hijacked by the same kinds of systems that currently hijack "To" to 
mean something other than it should? Sorry, I can't suspend my disbelief 
that far.

All you're doing is taking the next step in a losing battle -- even if 
the opponent is blithely unaware of the damage they are wreaking, it's 
still a battle and we're still going to lose.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 14 Jul 2008 15:09:17 -0400

> an @nostrum defined in the context of @eden. Something like a signed

Well sure, ALL of it COULD be changed. :)
(one could argue the P-Asserted draft is in fact proposing such changes)

The only point was it won't work as defined today.

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Mon, 14 Jul 2008 14:11:22 -0500

> an @nostrum defined in the context of @eden. Something like a signed 

Of you could express it cryptographically. Well-Known-Root signs @eden; 
@eden signs @nostrum. Recipient can examine the cert and determine 
whether they trust the chain.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 14 Jul 2008 15:42:05 -0400

> Sent: Monday, July 14, 2008 3:08 PM
>

Yup, that's possible.  It's possible for anything we do, no doubt.  But there is a difference: we're starting with it being signed.  If it becomes popular and people start hijacking and mucking with it, the signature fails, and they will be introducing call failures or errors into a previously working deployed system.  Customers don't like to introduce failures into an already working deployed system (the Spice must flow).  Today if you try to do 4474 and it breaks, you're the one introducing errors into a working deployed system.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Mon, 14 Jul 2008 14:48:48 -0500

On Jul 14, 2008, at 2:11 PM, Adam Roach wrote:

>> acceptance rules. One could potentially  also "compound @" so we  
>> have an @nostrum defined in the context of @eden. Something like a  
>> signed uunet route.
>
> Of you could express it cryptographically. Well-Known-Root signs  
> @eden; @eden signs @nostrum. Recipient can examine the cert and  
> determine whether they trust the chain.

Yes, that's pretty much what I meant by "adequately described  
acceptance rules".

The question is how do you decide whether to trust @eden to sign  
@nostrum? There is no delegation tree like in ENUM, so it has to be  
done based on a trust relationship (possibly a contract) between you  
and @eden. That's what we'd have to describe to extend RFC 4474  
transitively.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 14 Jul 2008 15:21:21 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
> Burger
>
> [SIP Forum Chair Hat On]
>

How is P-Asserter breaking SIP??

> or broken implementations.

The P-Asserter draft is an Informational one, for private use... just as P-Asserted-Identity was (rfc3325).  It's not asking for 4474 to be deprecated.

-hadriel

---

From: Michael Thomas <[email-masked]>
Date: Mon, 14 Jul 2008 12:57:16 -0700

> That would work if and only if the B2BUA owned a cert of the same domain as the From they changed it to.  That is actually not the case in practice, even when the From is an E.164.  It would also n…
That would be ideal if the b2bua was in fact part of the same administrative
domain of course. However, the "you break it, you own it" scheme obviously
couldn't require such a thing. As in the case of this mailing list 
breaking DKIM
signatures, the IETF could resign as IETF leaving the From: (or p-a-i or 
eieio
...) the same. At that point there's no ex(-im?)plicit binding between 
the sig
and the From: domain, but that probably doesn't make much difference if my
domain has ietf.org whitelisted for, oh say, mailing list traffic.

Like I said, not entirely satisfying but throw in some local and reputation
based whitelisting and it seems like a pretty plausible scenario for SIP 
too.

       Mike

---

From: Dean Willis <[email-masked]>
Date: Mon, 14 Jul 2008 15:03:30 -0500

On Jul 14, 2008, at 11:32 AM, Byron Campen wrote:

>>> Addresses or hostnames).  Those are the cases I'm trying to get  
>>> the information through.
>>
>>
>> interoperable.  In doing this "fixing", one can expect that the  
>> SBCs would be changing headers.
>>
>
> 	I would say I don't know whether I should laugh or cry, but  
> laughter is obviously much more fun. Seriously; how ridiculous do  
> things need to get before we can no longer keep a straight face? (I  
> gave up a while ago)
>

You're right, it's a Really Big Mess.

There are several mistakes we've made again and again that got us  
where we are:

1) Writing specifications dramatically ahead of implementation  
experience.

2) Hacking up bits of our core protocol model to appease the adherents  
of strict interworking with legacy phone systems, and accepting broken  
requirements from the same.

3) Using MUST to describe "does" in explicative text, thereby  
preventing RFC 2119 language from being useful in tabular comparison  
of implementations to the specification or to other implementations.

4) Multiple ways of doing things, including a P-header appeasement  
thing vs a "standard" solution.

5) Failure to deprecate the specifications and pieces of specs that  
either don't work or don't get used.

6) Demanding "perfect" security in the specification, when we know  
quite well that nobody will implement the security features,  
especially if they're hard to build or operate.

6) Refusal to deprecate a whole lot of cruft and revise the version  
number of the protocol. Trying to negotiate backward compatibility for  
every design mistake we ever made is a nightmare. Let's at least find  
a way to make this a bounded problem.

6) Listening to me when I'm wrong.

6) Not listening to me when I'm right.

7) Trying to count our mistakes on our fingers while we're busy typing.

--
Dean

---

From: Michael Thomas <[email-masked]>
Date: Mon, 14 Jul 2008 13:11:12 -0700

Can I make a suggestion to you, the chairs and the rest of the group? That
nothing be advanced in this area to PS until you have shown real and 
interoperable
versions that are deployed in real life situations? Not in the DS kind 
of rigor,
but at least _something_ that demonstrates that that this is a) not 
academic and
b) there's real community interest in deploying.

For DKIM, a small group of us (me, Murray from sendmail, Arvel from
Alt-n and others) kept on top of the spec and pushed out deployed code
sooner rather than later. This was a  huge help for both interoperability,
but much more importantly to test out to see where the real-life corner
cases are.

       Mike, who generally thinks that IETF needs more running code

Eric Burger wrote:
>> *for* an SBC that I've had given to me by different vendors at 
>> various shows is that they can "normalize" SIP and make SIP 
>> interoperability actually work between different vendors.  The SBC 
>> understands how exactly Vendor X speaks SIP and how exactly Vendor Y 
>> speaks SIP and can then enable the interconnection/interoperability.  
>> So the reality is that there are SBCs out there that view as part of 
>> their function to "fix" SIP so that it can be interoperable.  In 
>> doing this "fixing", one can expect that the SBCs would be changing 
>> headers.
>>
>> Regards,
>> Dan
>>
>> --

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 14 Jul 2008 17:19:01 -0400

> Sent: Monday, July 14, 2008 4:11 PM
> To: Eric Burger
> Cc: [email-masked]

Do you mean this in the context of the P-Asserter draft, or for rfc4474?
I'm fine with that for the P-Asserter draft.  I have no interest in updating it if no one uses it.  I submitted it before implementing in order to get feedback on whether people thought it was meaningless/useless in value, or provided anything worthwhile; and if anything needed to be corrected or taken into account for the mechanism.

So far, though, it's mostly just been complaints about why anyone would need anything other than 4474.  Now if we could only have gotten such a real-world deployment experience requirement before moving 4474 to PS...

-hadriel

---

From: Michael Thomas <[email-masked]>
Date: Mon, 14 Jul 2008 14:30:41 -0700

> Do you mean this in the context of the P-Asserter draft, or for rfc4474?

I mean with whatever it is that gets us closer to the day that there is
light at the end of a tunnel that could in principle lead us closer to the
shore of the quagmire that Dean so eloquently detailed.

> So far, though, it's mostly just been complaints about why anyone would need anything other than 4474.  Now if we could only have gotten such a real-world deployment experience requirement before m…

Indeed.

          Mike

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 15 Jul 2008 11:14:17 +0200

The starting point of the mistakes was tying any form of identity to the
transaction identity of the protocol. At least some of the problems
would not have existed if we had broken that link.

But that is way back in the fundamentals of the protocol design along
with the poor compatibility specification.

Regards

Keith 

> Behalf Of Dean Willis
> Sent: Monday, July 14, 2008 9:04 PM
> To: Byron Campen
> Cc: [email-masked]
> Subject: [Sip] How did we get here? (Was Re: Signing 
> P-Asserted-Identity)
> 
> 
> >> arguments *for* an SBC that I've had given to me by 
> different vendors 
> >> at various shows is that they can "normalize" SIP and make SIP 
> There are several mistakes we've made again and again that 
> got us where we are:
> 
> 1) Writing specifications dramatically ahead of 
> implementation experience.
> 
> 2) Hacking up bits of our core protocol model to appease the 
> adherents of strict interworking with legacy phone systems, 
> and accepting broken requirements from the same.
> 
> preventing RFC 2119 language from being useful in tabular 
> comparison of implementations to the specification or to 
> other implementations.
> 
> 4) Multiple ways of doing things, including a P-header 
> appeasement thing vs a "standard" solution.
> 
> 5) Failure to deprecate the specifications and pieces of 
> specs that either don't work or don't get used.
> 
> 6) Demanding "perfect" security in the specification, when we 
> know quite well that nobody will implement the security 
> features, especially if they're hard to build or operate.
> 
> 6) Refusal to deprecate a whole lot of cruft and revise the 
> version number of the protocol. Trying to negotiate backward 
> compatibility for every design mistake we ever made is a 
> nightmare. Let's at least find a way to make this a bounded problem.
>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 15 Jul 2008 09:23:26 -0700

On Jul 14, 2008, at 2:30 PM, Michael Thomas wrote:

>>
>> So far, though, it's mostly just been complaints about why anyone  
>> would need anything other than 4474.  Now if we could only have  
>> gotten such a real-world deployment experience requirement before  
>> moving 4474 to PS...
>>
>
> Indeed.

There are implementations of 4474 around and were long before it  
became and RFC but ignoring that ...

I asked some folks on this thread a few years ago for an example of a  
real deployment where it would not be possible to use 4474 as long as  
the SBC implemented 4474. I'm still waiting for an example of where it  
actually is broken. Hadriel  hypothesized a type of situation where it  
could be broken. That was the case where service provider A passed  
call to B who passed call C and they were not using E.164 numbers but  
were using email style addresses and the one in the middle wanted to  
do media steering or restrict what codecs where allowed.

Cullen <with my individual contributor hat on>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 15 Jul 2008 13:48:13 -0400

> Cullen Jennings
> actually is broken.

If the From is an E.164, then you're right transit providers can re-sign it anew, changing the From domain to their own.  There are several problems with this, though:
        a) It has a deployment problem; we'd need all intermediaries which change anything signed by 4474 to all support 4474 re-signing, for 4474 to be deployable.  Otherwise the signature will constantly fail.  If it constantly fails, no one will try to use it.  If no one tries to use it, the intermediaries have no reason to implement re-signing.  Ergo, Catch-22.
        b) It changes the From URI.  Of course many intermediaries already do that for other reasons, but it's not like we should *require* them to do it if the only reason they would need to is to re-sign a message.
        c) We shouldn't *want* to force the intermediaries to re-sign.  It just makes it hop-by-hop trust.  Unless of course you believe the things being changed by the intermediaries are such that they MUST NOT be changed by intermediaries for the purposes of identity, because they are inherent to the meaning/value of "Identity".  For some things I don't believe you or anyone really feel that - for example call-id and cseq.  The questionable one would be SDP.
        d) Re-signing is expensive; it's both validating the received one, and signing it again.  The transit provider business is about low cost.  So they'll just delete the identity headers rather than resign, if they even do anything.

> Hadriel  hypothesized a type of situation where it

Well, to be fair the one in the middle could have any number of reasons for changing things which would break the signature.  Call-id obfuscation, CSeq number re-writing due to various b2bua functions, changing SDP for transcoding or dtmf interworking, etc.  You or your company knows all the reasons as well as I do. :)

-hadriel

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 15 Jul 2008 21:14:15 +0100

Cullen,

Have you read draft-elwell-sip-e2e-identity-important? I think you will
find that gives a number of reasonable use cases.

John 

> Behalf Of Cullen Jennings
> Sent: 15 July 2008 17:23
> To: SIP List

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 15 Jul 2008 13:20:58 -0700

On Jul 15, 2008, at 10:48 AM, Hadriel Kaplan wrote:

> If the From is an E.164, then you're right transit providers can re- 
> sign it anew, changing the From domain to their own.  There are  
> several problems with this, though:
>         a) It has a deployment problem; we'd need all intermediaries  
> which change anything signed by 4474 to all support 4474 re-signing,  
> for 4474 to be deployable.  Otherwise the signature will constantly  
> fail.  If it constantly fails, no one will try to use it.  If no one  
> tries to use it, the intermediaries have no reason to implement re- 
> signing.  Ergo, Catch-22.
>         b) It changes the From URI.  Of course many intermediaries  
> already do that for other reasons, but it's not like we should  
> *require* them to do it if the only reason they would need to is to  
> re-sign a message.
>         c) We shouldn't *want* to force the intermediaries to re- 
> sign.  It just makes it hop-by-hop trust.  Unless of course you  
> believe the things being changed by the intermediaries are such that  
> they MUST NOT be changed by intermediaries for the purposes of  
> identity, because they are inherent to the meaning/value of  
> "Identity".  For some things I don't believe you or anyone really  
> feel that - for example call-id and cseq.  The questionable one  
> would be SDP.
>         d) Re-signing is expensive; it's both validating the  
> received one, and signing it again.  The transit provider business  
> is about low cost.  So they'll just delete the identity headers  
> rather than resign, if they even do anything.
>
>
That's a good list. Someone should make sure to capture the above so  
that we can see how 4474 compares to any other solution that is  
capable of providing end to end secure assertion about who's phone a  
user is talking and collaborating with.
> Well, to be fair the one in the middle could have any number of  
> reasons for changing things which would break the signature.  Call- 
> id obfuscation, CSeq number re-writing due to various b2bua  
> functions, changing SDP for transcoding or dtmf interworking, etc.   
> You or your company knows all the reasons as well as I do. :)
>

Just to be clear, I'm aware of lots of situations where the service  
provider A and C might want to do the extra things you mention but I  
am not aware of real deployments where service provider B needs to do  
the things beyond media steering and codec restriction. I'm happy to  
be educated.
> -hadriel

Cullen <in my individual roll>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 15 Jul 2008 18:41:49 -0400

> From: Cullen Jennings [mailto:[email-masked]]
>

Replace A or C or both to be an Enterprise, lather, rinse, repeat.
But there're also cases where even if A and C are providers, that B would want to transcode, strip or modify ISUP mime, and convert number formats; this seems especially true in international transit peering.  And they almost all seem to want to replace the call-id.

-hadriel <with my Red Sox hat on>

---

From: Dean Willis <[email-masked]>
Date: Wed, 16 Jul 2008 02:16:23 -0500

> determine whether they trust the chain.

I've been informed that despite what I incorrectly thought, transitive  
signing doesn't require any modification to RFC 4474.

The 4474 spec requires that the subject of the cert used to sign  
correspond to the domain of the From. This is different from requiring  
that the common names match. So any SBC can re-sign anything at any  
time and break nothing, at the expense of some crypto work.

So, let's say [email-masked] calls [email-masked]. Nostrum's AS might  
sign Adam's INVITE.  Cisco's SBC might verify the signature, munge the  
fields, mint itself a cert with a subject of "nostrum.com" (using its  
well-known Nostrum CA key to sign that cert!) , and then sign the  
request (replacing the Nostrum signature) using the new cert. Then [email-masked] 
  would verify Cisco's signature, and transitive trust is created. Of  
course this doesn't say anything about why Michael should trust that  
signature, although in this simplest case the rationale is obvious.  
But for a 3rd service provider "in the middle", it is much less obvious.

This is apparently how some people intended RFC 4474 to be used.  It's  
much looser cert-matching than we're specifying in draft-ietf-sip-certs.

Am I alone in being made nervous by this approach? It seems that I  
could, for example, use the well-known (hah!) softarmor CA cert to  
forge INVITES from our ADs, and unless you just happened to know that  
softarmor shouldn't be signing for Cisco and Neustar you're likely to  
believe me. After all, you believed the signature when I called you  
myself. Now, it does make it easier to track me down later . . . is  
that good enough?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 16 Jul 2008 14:36:03 -0500

Dean Willis wrote:

> request (replacing the Nostrum signature) using the new cert. Then 
> [email-masked]  would verify Cisco's signature, and transitive trust is 
> created. Of  course this doesn't say anything about why Michael should 
> trust that  signature, although in this simplest case the rationale is 
> obvious.  But for a 3rd service provider "in the middle", it is much 
> less obvious.
>

I've been informed that the above is also completely wrong. So I'm going 
to shut up until I can beat the truth out of somebody.

And we wonder why implementors have trouble with our specs!

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 17 Jul 2008 19:23:20 -0500

On Jul 16, 2008, at 2:36 PM, Dean Willis wrote:

> I've been informed that despite what I incorrectly thought,  
> transitive  signing doesn't require any modification to RFC 4474.

> correspond to the domain of the From. This is different from  
> requiring  that the common names match. So any SBC can re-sign  
> anything at any  time and break nothing, at the expense of some  
> crypto work.

> So, let's say [email-masked] calls [email-masked]. Nostrum's AS  
> might  sign Adam's INVITE.  Cisco's SBC might verify the signature,  
> munge the  fields, mint itself a cert with a subject of  
> "nostrum.com" (using its  well-known Nostrum CA key to sign that  
> cert!) , and then sign the  request (replacing the Nostrum  
> signature) using the new cert. Then [email-masked]  would verify  
> Cisco's signature, and transitive trust is created. Of  course this  
> doesn't say anything about why Michael should trust that  signature,  
> although in this simplest case the rationale is obvious.  But for a  
> 3rd service provider "in the middle", it is much less obvious.

Having beaten a new version of the truth out of myself (assisted by  
questions from Hadriel and Cullen), I now know that what I meant to  
say was subtly but critically different:

-------
I've been informed that despite what I incorrectly thought,  
transitive  signing doesn't require any modification to RFC 4474.

The 4474 spec requires that the subject of the cert used to sign   
correspond to the domain of the From. This is different from  
requiring  that the common names match. So any SBC can re-sign  
anything at any  time and break nothing, at the expense of some crypto  
work.

So, let's say [email-masked] calls [email-masked]. Nostrum's AS  
might  sign Adam's INVITE.  Cisco's SBC might verify the signature,  
munge the  fields, mint itself a cert with a subject of  
"nostrum.com" (using its  well-known Cisco CA key to sign that  
cert!) , and then sign the  request (replacing the Nostrum signature)  
using the new cert. Then [email-masked]  would verify Cisco's  
signature, and transitive trust is created. Of  course this doesn't  
say anything about why Michael should trust that  signature, although  
in this simplest case the rationale is obvious.  But for a 3rd service  
provider "in the middle", it is much less obvious.
------

I hastily typed "using its well known Nostrum CA key" instead of  
"using its well known Cisco CA key" in the last paragraph. I knew what  
I meant, I just typed the wrong word. Sorry.

This (as corrected) AFAIK cryptographically works. But it doesn't work  
any better than P-Asserted-Identity and TLS. It still lacks a  
reversible chain-of-trust that is visible to the end user.

I suppose the advantage is that, in the absence of an evil crypto- 
mangling SBC, you'd still get the benefit of end-to-end (or at least  
authentication server to verifier) RFC 4474, which MIGHT involve less  
transitive trust. But that doesn't seem too useful to me. I think it  
would be much better to just patch RFC 4474 to work through the SBC.

Another option would be to have each rewrite take the old request and  
wrap it in a a sipfrag body, then sign that request as part of the re- 
siging process. That way the final verifier would be able to work  
backwards through the chain of rewrites and verify each and every one  
of them. Of course, it one of the re-signing SBCs were more evil than  
usual, they'd still be able to lie to us about what was happening. But  
we'd be able to debug which SBC had "broken", from a diagnostic  
perspective.

--
Dean

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 17 Jul 2008 18:39:58 -0700

> Sent: Thursday, July 17, 2008 5:23 PM
> To: SIP IETF
> Subject: [Sip] Where Dean Went Wrong With Signing P-Asserted-Identity
> 
> 
> signature)  

Like other protocols (see below), SIP needs to identify who injected 
a message into the SIP network.

We can't identify who injected a message using RFC4474.  As described
above, RFC4474 only identifies the most recent hop.  As you point out, 
the most recent hop is already known because the signaling is SIP-
over-TLS.

Identifying who injected a message into a network is the same problem
that USENET had for its posts and its cancels.  For a few years you
could assume the last host in the Path: header injected the message,
but of course people started forging the Path: header when they
injected a message, causing misdirection.  With USENET, you could
start asking your neighbors and eventually learn which host really
injected a certain USENET message.  But this was not an appealing
solution.  To authorize 3rd party cancels and identify who injected
cancels into USENET, various mechanisms to sign 'cancel' messages were 
born.  (Of course, USENET growth has tapered off, especially with 
the recent killing of alt.coffee by the New York Attorney General).

Coming back to protocols the IETF has standardized:

Email also benefits from identifying who injected a message into the
email network, even when the message traverses alias expanders,
mailing lists, or had footers inserted ("The contents of this message
are proprietary, burn it if you aren't supposed to receive it").  DKIM 
was born.

Transport protocols experience blocking and interference from
firewalls -- much like SBCs block and interfere with SIP and RTP.
Blocking ICMP is the most famous:  ICMP messages are blocked by
mis-configured firewalls (if you are an IETF person) or blocked by
properly-configured firewalls (if you are a non-IETF person).  
Noticing this reality, and the lack of success with TCP PMTUD 
black-hole discovery in many implementations, RFC4821 was born.

Yet SIP continues to stand apart.

In Dublin we have an opportunity to drink real beer.  We should
also tackle one of SIP's real problems:  identity.

-d

---

From: Adam Roach <[email-masked]>
Date: Fri, 18 Jul 2008 15:32:50 -0500

On 7/17/08 7:23 PM, Dean Willis wrote:
> munge the  fields, mint itself a cert with a subject of "nostrum.com" 
> (using its  well-known Cisco CA key to sign that cert!) , and then 
> sign the  request (replacing the Nostrum signature) using the new 
> cert. Then [email-masked]  would verify Cisco's signature, and 
> transitive trust is created. Of  course this doesn't say anything 
> about why Michael should trust that  signature, although in this 
> simplest case the rationale is obvious.  But for a 3rd service 
> I suppose the advantage is that, in the absence of an evil 
> crypto-mangling SBC, you'd still get the benefit of end-to-end (or at 
> least authentication server to verifier) RFC 4474, which MIGHT involve 
> less transitive trust. But that doesn't seem too useful to me. I think 
> it would be much better to just patch RFC 4474 to work through the SBC.

The key difference is that one merely requires an explanation of how 
things can be made to work; the other requires development of Another 
Way To Do The Same Thing, which (in protocols) is pretty much always a 
bad thing -- to be reasonably interoperable, implementations are forced 
to implement both (or all of) the defined mechanisms.

/a

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 18 Jul 2008 14:38:40 -0700

> "nostrum.com" 
> things can be made to work;

Publishing a document that describes how RFC4474 is expected to work
with SBCs would be very valuable.  Such a document is long overdue.

-d

> the other requires development of Another