Subject: [SIP] Minutes of SIP Security task force in Adelaide

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 10 May 2000 21:04:19 -0400

Folks,

Enclosed are draft minutes of the SIp security task force meeting in
Adelaide. Remember, "consensus" here does not represent consensus of the
working group and this should be looked at more as a first step
discussion.

Thanks to Flemming for taking and preparing these minutes.

-Jonathan R.

Minutes of SIP Security Task Force meeting 
========================================== 
47th IETF meeting, Adelaide 

Prepared by Flemming Andreasen 

A number of people participated in the SIP Security Task Force meeting
in Adelaide on
Sunday 3/25/00 before the IETF meeting started. The purpose of the
meeting was to start
discussion on SIP security. 

1. Goal 
======= 
The following goals were established for the meeting: 
- Identify threats, what are the problems we are trying to solve: 
  o Authorization of callers, user-user authentication model 
  o SIP for secure media streams, encryption of media streams 

The following goal was suggested as well, however it was decided it may
not be in scope
for now: 
- Keying material for other things, e.g. for QoS admission 

It was then decided to divide the security discussion into two separate
areas: 
- Encryption 
- Authentication 

2. ENCRYPTION 
============= 
End-to-end encryption only works in the simplest cases. SIP never really
looked at
security from a system perspective, only from a relatively simple
protocol perspective. A
discussion about threats and trust models was therefore initiated. 

There are two types of attacks to worry about: 
- User attacks 
- Rogue proxies 

Rogue proxies are: 
- Proxies that do not do what they are supposed to do, e.g. maintain
privacy 
- Proxies that do things they are not supposed to, e.g. claim that calls
occur when they
didn’t by originating INVITEs. 

The rogue proxy issue led to a basic question; to what extent do you
actually trust that
a proxy does what it’s supposed to ? It was agreed that it would be very
complicated if
you trust the proxy to do some things, but not others, and hence the
model would be to
either trust the proxy or not. 

Furthermore, it was suggested, that trust would be either hop-by-hop or
end-to-end (not,
e.g., trust the next two hops). This led to a decision, that we need a
model that does
not depend on end-to-end security, but allows for it, while still
providing a useful
security service. The model for this will be to have hop-by-hop security
with
transitivity of trust and still allow for end-to-end security. 

As an added requirement on the hop-by-hop security trust model, it was
also decided, that
should a proxy route over an untrusted hop, the caller can request the
call be rejected
rather than continue with the call. 

This decision led to a long discussion about whether it works similarly
the other way,
i.e., can the called party decide to reject a call that has traversed an
untrusted hop.
It was eventually agreed, that it does work similarly the other way.
However, the only
thing you can do when a message has traversed an untrusted hop is to say
that the entire
message is untrusted (e.g., cannot say that certain fields are trusted
and others are
not). 

It was agreed to use the above as the foundation for the security model
for encryption. A
discussion on encryption mechanisms then started. 

Jonathan Rosenberg opened the discussion by suggesting that: 
- SIP encryption (not authentication) should be deprecated, because: 
  o It doesn’t work with NAT and firewalls 
  o It assumes you know the public key of the party you are calling,
which is not a good
assumption. 
  o It only really hides the body (and again that doesn’t work well due
to the above). 

Initial discussion of these points led to the decision that it should
still be possible
to support end-to-end encryption as there may be some uses for it. 

A problem with the current end-to-end encryption scheme is, that it
relies on knowing the
public key of the other party. One way of solving that is to return a
public key in the
response and simply do a re-INVITE then. However, it was agreed that we
should not do
that, as we effectively end up duplicating IKE, or something similar. 

Dave Oran suggested that end-to-end information that needs encryption
should simply go in
the body (don’t encrypt headers). We could use multipart for this, or
simply allow for a
single body to be encrypted and define an error code to be returned if
the proxy needs to
see the body (e.g. if SDP is encrypted and message traverses a
firewall). The group
decided to accept this mechanism. The error code will only support
coarse granularity,
i.e., if multiple bodies are encrypted, you will not be told which one
is needed in
clear, just a general error saying “body not understood”. 

Additional discussion on encryption of headers ensued. Contact is an
example of header
that can be usefully encrypted (end-to-end), but in general, there
doesn’t seem to be a
whole lot of use for this (generally, if the information is relevant it
can’t be
encrypted). Only want the registrar to see the Contact, not any of the
intermediate
proxies. 

It was then proposed, that rather than having the present encryption
mechanism, we only
encrypt bodies. For those rare SIP headers that you would want to
encrypt end-to-end you
may want to have some kind of “SIP-header” body part encrypted with e.g.
S/MIME (although
S/MIME is not viewed upon favorably by security people). PGP is there
now, but it is not
usefully deployable. 

This concluded the encryption discussion with the following recap of the
encryption
requirements identified: 
- Support encryption of some headers (Contact is the one useful example
so far). 
- Prefer encrypted headers (not headers with encrypted content) to end
up in body-parts
rather than in SIP header. 
- Some bodies may have to be encrypted (not necessarily all) 
- Be able to send INVITE without end-to-end security, get some kind of
response back from
remote party telling you to do it securely, and re-issue INVITE (w.
security this time).
Not clear what the exact mechanism is for this, e.g., return public-key,
certificate, or
something outside of SIP. 
- Be able to send INVITE with end-to-end security first time around. 

3. AUTHENTICATION (end-to-end) 
============================== 
We have the following potential authentication requirements: 
- Called party id 
- Calling party id 
- Who we thought we were calling 

It is not clear there is any way to achieve this reliably (securely)
unless we have
end-to-end authentication. The problem with end-to-end authentication
is, that it implies
we (a proxy) cannot rewrite any of the information. 

Brian Rosen wanted to have SIP carry some information that
allows/supports end-to-end
authentication. 

Dean Willis wanted to transport messages across untrusted proxies and be
able to detect
what (and how) a message was altered/rewritten. Dean noted that there
are three
possibilities for what can happen to a message: 
- It is not modified 
- It is modified 
- Parts of it are deleted 

It was then suggested that From, To, and Bodies should be authenticated,
however
agreement was not achieved on this. 

Dave Oran then noted that X.400 had solved similar issues and pointed
out the parallels
to headers, bodies and envelopes. It was suggested that we adopt a
similar model. 

This lead to the following tentative decision (not clear if this was in
fact agreed to,
however nobody objected): 
- SIP headers are hop-by-hop (period) 
- Anything above the auth header may be modified hop-by-hop 
- Anything below the auth header is end-to-end (allow for duplication of
fields, e.g. To
and From ) and cannot be modified. 

3.1 Hop-by-hop Authentication 
============================= 
Based on the above, the discussion then moved on to focus on hop-by-hop
authentication. 

It was stated that, that we cannot assume availability of public key
cryptography on an
end-system (UA), however we can assume that proxies have public key
cryptography support. 

It was furthermore stated that, we want to differ between security for: 
- Server to server 
- Client to server 

Currently SIP does not specify how you do hop-by-hop security, only that
you can do it.
We want to have at least one mechanism specified in the SIP
specification. 

It was decided that we should have the following hop-by-hop security
mechanisms: 
- Server to server: IPSec using ESP transport, 
- Client to server: IPSec using ESP transport (not clear ESP transport
was agreed to) 

It was then suggested (however Jonathan Rosenberg did not want to
declare consensus yet),
that the following keying/authentication mechanisms should be used: 
- Server to server: Kerberos (with PKCROSS between realms) 
- Client to server: Kerberos (either with shared keys or PKINIT) 

The question about whether we need (hop-by-hop) authentication for both
devices and
applications was then asked. It was agreed that we only need it for
applications as we
can always have a default user on the device if no “real” user is logged
in.  The
Security Association established identifies the user. For a gateway, the
“user” is the
gateway. For a device with multiple users on it, the device itself will
then have to
authenticate the users, unless you have a separate Security Association
for every single
user (which you probably don’t want to). 

Dean Willis and Robert Sparks objected that you need app-level security
when you don’t
have transitivity of trust, and there are applications where you do not
have transitivity
of trust. For example, consider a call where you involve multiple
providers for that call
(multi-proxy authenticate). Basically, it’s not enough to have either
end-to-end or
hop-by-hop security; you also need to have end-to-intermediate security. 

This was a different model than had been worked on for the majority of
the meeting
however no one argued against the validity of it. Since it contradicts
some of the
earlier assumptions and decisions made during the meeting, each of these
will have to be
revisited. 

4. Miscellaneous 
================ 
In addition to the above, the following security related issues were
raised as well: 

4.1 Areas needing further work 
============================== 
- Challenge-response doesn’t work with forking (but addresses replay) as
only one 401
will get back to the caller. 
- Want to have a security scheme that works with forking (but may not
address replay). 

4.2 CANCEL security 
=================== 
- If we have hop-by-hop security and we only accept CANCEL from previous
hop, is CANCEL
security hole then closed ? 

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 13 May 2000 04:45:41 -0400

> A number of people participated in the SIP Security Task Force meeting

Must have been a really secure meeting if the identity of the
participants is secret :-)

> - SIP encryption (not authentication) should be deprecated, because:

I strongly disagree with this. SIP encryption serves a number of useful
purposes. It hides information, for example, about Contact, Subject,
Organization, Retry-After, media types, media IP addresses and meeting
times (in SDP), SDP k= keys, etc. All of these are irrelevant for proxy
routing behavior, but highly sensitive. 

>   o It doesn’t work with NAT and firewalls

That's a risk you take. I refuse to dumb down protocols for everybody
just because some people are behind firewalls and NATs. There are lots
of protocols or features that you can't use behind a firewall or NAT.

>   o It assumes you know the public key of the party you are calling,

It works in many cases. In other cases it can be made to work, e.g., via
indirection.

>   o It only really hides the body (and again that doesn’t work well due

See above.

> to support end-to-end encryption as there may be some uses for it.

Agreed.

> clear, just a general error saying “body not understood”.

I had originally (many years ago) suggested a similar mechanism,
assuming I understand your proposal correctly, namely to have a body
type "SIP message", which is encrypted. A decision was made not to do
this (I'm afraid I no longer remember the reason; might have been
message size concerns or processing logic). If you only want to encrypt
SDP, I disagree, for the reasons stated above. If you want to do both
and use the "SIP message" body mechanism, I'm not against this, but this
does entail a significant protocol change, without changing any of the
other problems.

> encrypted). Only want the registrar to see the Contact, not any of the

Again, I disagree, see above.

> We want to have at least one mechanism specified in the SIP

Why? This gets into endless arguments as to which is better.

> - Client to server: IPSec using ESP transport (not clear ESP transport

Disagree. For practical reasons, TLS is much easier to deploy (keying,
available libraries, available infrastructure to obtain keys, etc.). Are
there any technical reasons to force somebody to implement IPsec?

> 4. Miscellaneous

This can be solved, at the cost of increased proxy complexity, by having
the proxy gather all challenges from all branches and return them in the
401 response, similar to multi-proxy authentication.

---

From: Michael Thomas <[email-masked]>
Date: Sat, 13 May 2000 09:21:46 -0700 (PDT)

> It works in many cases. In other cases it can be made to work, e.g., via

   Just as a general note -- again -- any
   dependence on public key signatures/encryption
   on a per message basis will not scale. They
   may work in toy systems, but when you start
   talking about systems which must do 10-100's
   of transactions per second, they simply do 
   not scale: it is simply beyond the state of
   the art by several orders of magnitude.

   I have no particular qualms about having the
   ability to use public key operations as a
   quick and dirty (and stateless) way to do
   crypto, but we *must* have the ability to
   take anything which used a public key operation
   before and have a symmetric key analog for it,
   and SIP's must support it as a basic mechanism.   

   Obviously, symmetric key operation begs the 
   question of key distribution, of which there
   may be many choices -- I personally think that
   kerberos covers the most bases in a scalable
   fashion, though not all. However, even if the
   the key distribution is done by Palantir, we
   have to have a way to do this.

   I'm somewhat ignorant of PGP, so forgive me
   if this already part of it. All public key
   signatures and encryptions still rely on 
   symmetric key operations: signatures do a
   SHA-1 HMAC over the message and then encrypts
   the resulting hash with their private key. Encryption
   cons's up a key and runs 3DES over the message.
   It then encrypts the key itself with the
   sendee's public key. 

   In both cases, there is a base level symmetric
   key operation which is common. This should be
   abstracted such that either symmetric key or
   public key operations are a choice which is
   discernible at the receiver. As I read 2543
   right now, however, there seems to be a base
   level assumption that it is *always* done
   through public key.  If PGP doesn't allow 
   for symmetric key only, then the entire 
   mechanism is incomplete and needs to be 
   fixed. Even if PGP doesn't make that 
   assumption, it would be very nice in 
   2543bis to actually show that you don't need
   to always use public key operations as the
   current text is highly misleading.

 > Why? This gets into endless arguments as to which is better.

   There were no endless arguments in MEGACO about
   this, which argued about everything endlessly.

 > there any technical reasons to force somebody to implement IPsec?

   Yes: there is no such thing as TLS over UDP.
   Even if there is some experimental UDP based
   version, it negates the advantages you list
   above. Also: which OS's don't have IPsec these
   days? 

   Beyond that, TLS is the worst of all possible
   worlds: if I'm a programmer, I either want to
   have fine control on what portions of the
   stream I diddle at the added complexity of 
   understanding how the API and functionality
   works, or I want to be completely ignorant of
   what goes on at a lower layer. 

   TLS, however, requires that I learn the API
   *and* gives me none of the benefits of fine
   control. IPsec at least has the know-nothing
   property; the application can remain utterly
   ignorant. Considering the pathetic state of
   security right now, anything that puts a 
   requirement for a program to touch *anything*
   is tantamount to saying that it won't happen
   any time soon. IPsec at least gives users
   a third party frob to compensate for
   application inadequacy; TLS does not.

	       Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 13 May 2000 18:28:36 -0400

>    may work in toy systems, but when you start

They work just fine (modulo the PKI problem) in anything *but*
large-scale PSTN gateways. Presumably, gateways are a transient (albeit
important) problem.

>    have to have a way to do this.

I have yet to see a scalable, inter-domain Kerberos system. What makes
you believe that this is easier than regular public key?

Most intelligent-endsystem (as opposed to PSTN gateway) calls will be
essentially random and sparse in time, with intervals between calling
the same system longer than the ticket lifetime, so that rekeying will
be needed for each call. I can't imagine that this scales any better.

>    current text is highly misleading.

Again, except in the case of high-volume signaling trunks between
gateways, interarrival times for calls between the same
source-destination pair may well exceed customary ticket lifetimes. If
we do have high-volume signaling trunks, we have existing resaonably
efficinet mechanisms (IPsec, TLS) to handle this. I'm really reluctant
to cook up a new mechanism until we know that the existing ones cannot
do the trick.

>    this, which argued about everything endlessly.

What's your concrete proposal? We'll see what arguments we get (or
not...).

>    Yes: there is no such thing as TLS over UDP.

For high-volume signaling trunks where key exchanges and operations
matters, TCP is probably the more appropriate solution.

>    above. Also: which OS's don't have IPsec these

Windows 98 and Windows NT come to mind, at least out of the box. From
all that I heard, most of the IPsec versions do not interoperate across
OS or implementations. I believe there was even a report on installing
IPsec on this list which struck me as basically requiring deep IPsec
understanding to make anything work.

Again: I have no problem with IPsec. I do have a problem with not
supporting TLS.

>    application inadequacy; TLS does not.

How come that millions of web servers and other applications actually
use TLS, on a daily basis?

---

From: Michael Thomas <[email-masked]>
Date: Sun, 14 May 2000 13:30:30 -0700 (PDT)

> large-scale PSTN gateways. Presumably, gateways are a transient (albeit

   Um, no. Proxies which need to scale to 10's
   or 100's of thousands of users have the same
   problem. With current state of art, you could
   not build a proxy that big which requires public
   key operations. Low end gateways (25Mhz class) 
   take hundreds of milliseconds -- I've heard
   going on a second -- to do one public operation.
   That is directly in the path of post dial
   delay.

   I don't see how you can handwave those issues
   away as unimportant. Large scale SIP
   deployments are hopefully going to do better
   than the PSTN -- and the rest of the Internet
   -- on security, but it certainly will not and
   can not happen if the bar is set too high.

   Also: it's telling that you brush the PKI
   problem aside as a detail. There's a reason
   why there's no such thing as a large scale
   PKI after 20 years of having the base technology: 
   they're incredibly hard -- maybe insurmountably
   hard -- things to build.

 > you believe that this is easier than regular public key?

   Well, for one it allows you to vastly scale
   down the reliance on public key infrastructure
   to a set of potentially high-touch machines
   (the KDC). Are you familiar with PKCROSS?

   Besides, you can do quite a lot with Kerberos
   without ever even getting into the cross realm
   tar pit. 

 > be needed for each call. 

   Well, there are more things than PSTN gateways
   which have scaling problems. IVR maze machines,
   conference bridges, proxies, etc, etc, will
   have identical scaling concerns. Kerberos
   tickets can also have a long lifetime --
   days, weeks even. While it's questionable
   whether my IP phone at home would want to
   to have a service ticket for the end to end
   call, it's unquestionable that it would be
   a benefit to use Kerberos to key up the SA
   between the UA and its first hop proxy. *One*
   *call* would be enough to amortize the cost.
 
>  I can't imagine that this scales any better.

   The only thing you can say is that Kerberos
   degenerates into public key case in
   pathological situations. That's not a very
   strong starting point.

 > source-destination pair may well exceed customary ticket lifetimes. 

   End to end is not the only consideration. In
   fact, it's the least interesting because I 
   might just as well ship the end to end SIP keying
   material through in the initial INVITE as plain
   text if the destination is in the same trust
   domain as the KDC. 

 >If
 > efficinet mechanisms (IPsec, TLS) to handle this. 

   I hope that you're not thinking that IPsec with
   IKE to do end to end keying would be viable
   between trunking gateways and high fan out
   UA's. TLS would be no better.

 > I'm really reluctant

   Kerberos is a new mechanism? I guess if you
   consider the late 80's "new". SIP, and maybe
   HTTP, are conspicuous in their lack of a
   Kerberos mechanism. You can even use Kerberos
   to key RSVP integrity objects.

   And I don't know how much more you need to
   "know" here: I work for a manufacturer of
   a lot of the components that would be needed
   in a large scale SIP system. I know that it
   cannot be built now as specified, and I'm
   doubtful that it can be built any time soon. I
   do know, however, that a relatively simple and
   well understood piece of technology can make the
   entire problem moot. It seems like a no-brainer
   to me.

   Also as a point of reference: I think that
   SIP should recommend IPsec as the base hop
   by hop security mechanism. I don't think it
   needs to say anything about which key
   distribution protocol is recommended though.
   I have my opinions, but the spec doesn't need
   to reflect them.

 > What's your concrete proposal? We'll see what arguments we get (or

   The full protocol is being worked on as we
   speak. You can also look at the security spec
   on packetcable.com to get an idea of how you
   can do Kerberized IPsec for SIP. It's currently
   spec'd for MGCP, but the transported protocol
   is actually irrelevant.

 > matters, TCP is probably the more appropriate solution.

   That's highly arguable; I'm sure the SCTP folks
   might have thought or two about that, and as
   far as I can tell, they have the full support of
   their AD's. 
 
 > Windows 98 and Windows NT come to mind, at
 > least out of the box. 

   Win2k and presumably (?) that other Windows
   market churner will have it. And you can always
   do bump in the stack and bump in the wire
   implementations of IPsec.

 > From
 > OS or implementations.

   The problem isn't IPsec usually, the problem is 
   with IKE. 

 > Again: I have no problem with IPsec. I do have a problem with not

   But TLS doesn't address one quite legitimate
   and useful operational mode of SIP: UDP with
   ALF. That's quite a shortcoming. If we
   recommend any hop by hop security, it at the
   very least needs to work with all operational
   modes of SIP.

	    Mike

---

From: "Michael Welser" <[email-masked]>
Date: Mon, 15 May 2000 14:24:13 +0200

> of protocols or features that you can't use behind a firewall or NAT.

This opinion (attitude?) leads eventually to the discussions last heard
in foglamps.

I do not like NATs. But NATs are here, and they are reality for more
than just "some people" (most of which do not even have a say about
this) and they will be with us for quite some while.

I refuse to smarten up protocols for everybody (thereby cutting off
potential users from potential services) just because some people are
NOT behind firewalls and NATs. There are some protocols or features that
you can use behind a firewall or a NAT (otherwise the Internet wouldn't
be what it is now).

Michael Welser

------------------------------------------------------------
mailto:[email-masked]         Telekom Austria AG
tel: +43 (1) 79711 1622                               Abt RS
fax: +43 (1) 79711 1608                    Arsenal Objekt 22
http://www.telekom.at                           Postfach 111
http://www.aon.at                                A-1103 Wien

---

From: "Robert Johnson" <[email-masked]>
Date: Mon, 15 May 2000 12:42:18 -0500

>you can use behind a firewall or a NAT (otherwise the Internet wouldn't

If we do not interwork with NATs, SIP will not fly. Most commercial Internet
subscribers today pass through a NAT, whether they know it or not. However,
deprecating SIP encryption forces implementers into incompatible product and
network configurations, which is also a limiter to the growth of SIP. Like most
enterprise H.323 implementations, most SIP implementations will operate
completely within the enterprise domain, going outside through a proxy that is
positioned to avoid the NAT/FW issue entirely. This, along with other
arguments, leads me to think that deprecating SIP encryption is not necessarily
the wisest move.

Robert Johnson
Director of Network Architecture
Advent Networks
(512) 397-4914

SIP mailing list
[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 15 May 2000 17:33:02 -0400

> 401 response, similar to multi-proxy authentication.

This is an interesting idea. I like it. An interesting question arises
when you get *both* 401s and 407s. I guess the proxy could return a 401,
and place into the 401 WWW-Authenticate headers from the 401s it
received, and Proxy-Authenticate headers from the 407s. A UA would need
to be smart and look for both headers in a 401, however. Any other
interactions...?

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 15 May 2000 16:38:42 -0400

Rather than do nesting of >, maybe we can make progress by summarizing,
as several different problems seem to be discussed at the same time:

- e2e authentication and/or encryption across domains:

Useful primarily for authenticated call filtering and key exchange for
media encryption. Scalable probably for intelligent end systems, at the
possible penalty of call setup delay. If truly e2e, requires per-user
public keys, which do not seem imminent (although some organizations are
apparently working on this, mostly for internal purchasing use).
Semi-e2e might use Kerberos, local proxy digest authentication or other
h2h mechanism (see below) to authenticate and secure the local hop, with
proxy-secured signaling. This only requires a PK for each organization,
readily obtained from Verisign and their various competitors that would
be recognized in web browsers. This would essentially be a model similar
to today's web model, which seems to work satisfactorily in the absence
of a true PKI. Proxy-based security probably scales easily (in the
typical CPU-dedicated-to-server installation) to a few thousand calls a
day (i.e., it would work for typical departments), based on rough
assumptions of SSL servers. (Is there an SSL/TLS benchmark test for web
servers?) [TLS plays no role here, just probably has similar
performance.]

- h2h mechanisms *across* domains

This seems to be the hard problem. Just specifying IPsec without an IKE
doesn't help much to achieve interoperability. Is it even plausible to
run basically every single IKE version and variation on a proxy, to be
able to talk to every other domain? Would PKCROSS be sufficiently
acceptable to every other proxy operator to use it exclusively? Is there
operational experience with large-scale use of this? The number of
public key operations would seem to be the same with PKCROSS or direct
proxy-to-proxy use of some IKE or TLS, depending solely on the sparsity
of proxy relationships. PKCROSS would presumably have the advantage of
splitting this across two (sets of) machines, but unless this is used
for something else much "bigger" and can thus ride the coattails of an
existing application, the net number of boxes seems comparable.

For TLS, while restricted to TCP, there's operational experience and a
well-known infrastructure for obtaining certificates; most organizations
would already have such a certificate for their secure web server.

This problem seems much harder than that faced by typical sigtran or
MGCP/Megaco applications, where (for Megaco) this is mostly intradomain
or for sigtran a smallish number of well-known peers instead of every
ISP and organization-with-a-SIP-address on the planet.

Thus, the scalability depends on the fraction of SIP calls that require
SA setup. One could presumably look at mail server logs to see if, say,
80% of the messages go to 100 domains with lots of traffic per PK
operation, so that only 20% would require per-call SA establishment.
Besides the usual 80-20 rule, I have no indications what, if any,
scaling advantage will accrue due to such uneven distribution of call
destinations.

- h2h *within* a domain

Relatively easy, since one can agree on either a single IKE or (most
likely currently) IKE implementation, with alternatives such as Kerberos
or just about anything else feasible according to what's available
locally. (E.g., Microsoft-only shops might use the Microsoft flavor and
not care about any interoperability problems with the rest of the world.
Or, for authentication only, somebody might draw on CHAP
authentication.) Specifying a single or small number of architectures is
probably helpful, but to a somewhat more limited extent than in the
inter-domain case, since single organizations usually have a mechanism
to agree on things. Specifying Kerberos seems like an easy step forward
here. If applications use GSSAPI, this is probably largely invisible to
the application writer.

Henning