Re: : FW: IPSec use with Diameter (from the IPSEC WG list)

Scott G. Kelly wrote:

> Personally, I don't care if you change 
> the text, add errata, or leave it alone. Being one with direct 
> implementation experience contradicting the text, I only meant to answer 
> the question that was posted.

Right. Thanks for that...

> It is true that no protocol bindings occur in phase 1, and this 
> complicates the task of using certs with granular (per-port) policies in 
> IPsec, but what this says is wrong. It *is* possible to use uniquely 
> configured root CAs for each application individually (assuming each 
> application has its own port). The PAD described in 2401bis makes this 
> more explicit, but it was allowed by 2401 and the IKE rfc family as well.

I tend to agree.

> I personally implemented a system with this capability, and took pains 
> to ensure that it was compliant with the various 24xx series IPsec RFCs. 
> I know for certain of at least one other implementation which provides 
> this capability, and I think there may be others. Granted, it is more 
> challenging to implement than, say, a more restrictive UI, and not many 
> paying customers actually need such functionality (although one is 
> apparently described in the rfc3588 text above). So, in the interest of 
> rapidly shipping product, many vendors probably don't support this. But 
> there is nothing in the spec which prevents one from doing so - it would 
> strictly be an implementation decision.

Right. I also had an implementation that was able to do this.

There's also a distinction between something that is allowed
by a spec and something that is required by the spec. I think we all
agree that these things can be done, but the question is to which extent
implementations do, and whether implementations that don't do are
non-compliant. My gut feeling is that prior to RFC 2401bis, there
were no requirements which forced implementations to do this. (I'm
not even sure if its mandatory in bis).

(Also, there are aspects of "application granularity" that go beyond
port numbers. You might want to connect to both A and B using the
application but still disallow some operations for A that are allowed
for B. This tends to be easier with TLS, although once again IPsec
implementations could provide an API which helps in these decisions.)

Anyway, my suggestion would be to send in a correction to the text,
implying that the issue is more in what implementations choose to
do and what they are minimally required to do rather than something
which theoretically prevents this. Here's a suggestion:

   Note that IPsec implementations can be considerably less flexible than
   TLS when it comes to configuring root CAs. Since use of Port identifiers
   is prohibited within IKE Phase 1, not all IPsec implemenations may be able
   to uniquely configure trusted root CAs for each application individually;
   the same policy must be used for all applications. This implies, for
   example, that a root CA trusted for use with Diameter must also be
   trusted to protect SNMP. These restrictions can be awkward at best.
   Since TLS supports application-level granularity in certificate
   policy, TLS SHOULD be used to protect Diameter connections between
   administrative domains. IPSec is most appropriate for intra-domain
   usage when pre-shared keys are used as a security mechanism."

--Jari