Subject: RE: [AAA-WG]: FW: IPSec use with Diameter (from the IPSEC WG list)

From: <[email-masked]>
Date: Tue, 7 Dec 2004 13:38:55 +0200

>  >> Here is one paragraph from RFC 3588 (Diameter Base Protocol):
>  >>
>  >> "Note that IPsec is considerably less flexible than TLS 
> when it comes to
>  >> configuring root CAs. Since use of Port identifiers is prohibited
>  >> within IKE
>  >> Phase 1, within IPsec it is not possible 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."
> 
> Scott G. Kelly wrote:
> 
>  > It's wrong. Granted, the original IPsec RFC's were not very clear on how
>  > you configure something like this, but what is discussed above is an
>  > implementation problem probably resulting from a design decision to only
>  > permit one IKE SA between a given endpoint pair. It has always been
>  > possible to use granular per-port policies, and if a particular
>  > implementation does not support this, it's not because of a restriction
>  > in the IPsec standard.

Have suggestions for an eratta entry?

John

---

From: Jari Arkko <[email-masked]>
Date: Tue, 07 Dec 2004 14:16:13 +0200

> Have suggestions for an eratta entry?

John, do you remember why we put it in this
text? I have a vague memory that it had to do with
a wish from the IESG that the limitations of IPsec
usage across domains needs to be described. Was this
so? Are all such limitations found to be non-existent?
I think not, although the text in question might be in
error.

Is Scott's concern that specification-wise, everything
is possible? I think the original concern had more to
do with practical implementations and experience than
what would theoretically be possible. Perhaps this
is the part that should be clarified, whether the
issue is with specs or with common implementations?
Or is the issue simply no longer relevant at all?
Or is it not relevant if you use RFC2401 and PAD?

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 07 Dec 2004 17:29:00 +0200

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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 07 Dec 2004 21:02:01 +0200

Scott G. Kelly wrote:
> I didn't comment on it before, but the reference to pre-shared keys here 
> confuses me. In IKEv1, use of PSK's is even more restrictive than use of 
> certs. Since they must be identified by the IP of the peer, there can 
> only be one psk per peer pair (say *that* three times really fast). How 
> does that solve the cert problem described here?

I'm not sure. The certificate usage issue may be orthogonal.
I do know some people have worried about how long certificate
chains (possibly needed on an interdomain case) pass through
UDP and how well fragmentation is supported over various cases.

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 7 Dec 2004 23:35:54 -0800 (PST)

> text?

I don't believe that the text is incorrect.

While the IKEv1 initiator may know what port the phase I SA is intending
to protect, the responder cannot know this because that information is not
included in the IKEv1 phase 1 exchange.  It doesn't matter how many phase
1 SAs are brought up between the two endpoints.  The responder has no idea
what the phase 1 SA is being brought up for, and so is unable to enforce
different certificate policies based on the (undisclosed) application.

In phase 2 the information is available, but by then it's too late.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 7 Dec 2004 23:40:27 -0800 (PST)

> more explicit, but it was allowed by 2401 and the IKE rfc family as well.

Without a protocol binding in phase 1, there isn't a way for the responder
to know what the SA is being brought up for.  Therefore it has no way to
tell the initiator what certs it will accept.  It can give the initiator
the union of all possible trust anchors, but then it once phase 2
completes, it is possible that the responder will learn that the initiator
chose the wrong certificate.  This isn't fixed in 2401bis, because it's
an inherent problem with IKEv1.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 08 Dec 2004 13:16:55 +0200

> an inherent problem with IKEv1.

Theoretically, the initiator can be guided by configuration to choose
the right certificate for the purpose that the phase 1 is being brought
up for. This works as long as the responder is willing to accept any of
the trust anchors. At the time phase 2 is being brought up, an
authorization decision can determine whether the initiator did the
right thing.

But this is very brittle, does not involve any explicit communication
over the protocols, and relies on correct configuration and knowledge
about what the other side expects. As a result it may not be very easy,
particularly in an inter-domain case.

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 8 Dec 2004 05:34:55 -0800 (PST)

> particularly in an inter-domain case.

This was exactly the limitation that RFC 3588 is talking about.  Note that
it is possible that the certificates themselves may be different in
important ways.  And the Responder might itself require a different
certificate. For example, a certificate for use of RADIUS over IPsec
might be different between a RADIUS client and server.  In that case the
Responder doesn't even know if the certificate is valid for the intended
usage, or which certificate it is to use itself, until Phase 2.