Subject: [AAA-WG]: Issue 254: More details needed on Diameter IPsec usage - Need Comments

From: <[email-masked]>
Date: Tue, 26 Feb 2002 22:45:45 +0200

Hello all,

The proposed text seems to be adding additional requirements -
we need to have some discussion on this before I can
make a decision on whether to support this or not.

John

Issue 254: More details needed on Diameter IPsec usage 
Submitter name: Bernard Aboba [email-masked] 
Submitter email address: [email-masked] 
Date first submitted: 28-Dec-01 
Reference: 
Document: base 08 
Comment type: Technical 
Priority: S 
Section: 2.2 
Rationale/Explanation of issue: 
The IPsec mode is not specified. IPsec is also mispelled (do a global 
replace of IPSec with IPsec). 

Add: 

"All Diameter implementations MUST support IPsec ESP [RFC2406] in transport 
mode with a non-null transform to provide per-packet authentication, 
integrity protection and confidentiality, and MUST 
support the replay protection mechanisms of IPsec. 

Diameter implemenations MUST support IKE for peer authentication, 
negotiation of security associations, and key management, using the 
IPsec DOI [RFC2407]. Manual keying MUST NOT 
be used since it does not provide the necessary rekeying support. 
Diameter implementations MUST support peer authentication using a 
pre-shared key, and MAY support certificate-based peer authentication 
using digital signatures. Peer authentication using the public key 
encryption methods outlined in IKE's sections 5.2 and 5.3 [RFC2409] 
SHOULD NOT be used. 

Conformant implementations MUST support both IKE Main Mode and Aggressive 
Mode. When pre-shared keys are used for authentication, IKE Aggressive Mode 
SHOULD be used, and IKE Main Mode SHOULD NOT be used. When digital signatures 
are used for authentication, either IKE Main Mode or IKE Aggressive Mode MAY 
be used. In all cases, access to locally stored secret information 
(pre-shared key, or private key for digital signing) must be suitably restricted, 
since compromise of the secret information nullifies the security properties of 
the IKE/IPsec protocols. 

When digital signatures are used to achieve authentication, an IKE 
negotiator SHOULD use IKE Certificate Request Payload(s) to specify the 
certificate authority (or authorities) that are trusted in accordance 
with its local policy. IKE negotiators SHOULD check the pertinent 
Certificate Revocation List (CRL) before accepting a PKI certificate for 
use in IKE's authentication procedures. 

The Phase 2 Quick Mode exchanges used to negotiate protection for 
Diameter connections MUST explicitly carry 
the Identity Payload fields (IDci and IDcr). The DOI provides for 
several types of identification data. However, when used in conformant 
implementations, each ID Payload MUST carry a 
single IP address and a single non-zero port number, and MUST NOT use 
the IP Subnet or IP Address Range formats. This allows the Phase 2 
security association to correspond to specific TCP and SCTP 
connections. 

Since IPsec acceleration hardware may only be able to handle a limited 
number of active IKE Phase 2 SAs, Phase 2 delete messages may be sent 
for idle SAs, as a means of keeping the number of active Phase 2 SAs to 
a minimum. The receipt of an IKE Phase 2 delete message SHOULD NOT be 
interpreted as a reason for tearing down a Diameter connection. 
Rather, it is preferable to leave the connection up, and if additional 
traffic is sent on it, to bring up another IKE Phase 2 SA to protect it. 
This avoids the potential for continually bringing connections up and 
down. 

If an IKE implementation receives a Phase 1 Delete message for a Phase 1 
Security Association bound to one or more sessions, then it SHOULD 
delete the associated IKE Phase 2 security associations."

---

From: Don Zick <[email-masked]>
Date: Tue, 26 Feb 2002 16:41:32 -0500

I don't understand why we care about specifying IPsec usage details.  My
understanding is that the Diameter server itself need not even know that IP sec is
in use.  Is this correct?  If so, it would seem to me that the details of how an
administrator configures IPsec in a network need not be mandated in the Diameter
drafts.

Thanks,
Don

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 26 Feb 2002 13:17:26 -0800 (PST)

> administrator configures IPsec in a network need not be mandated in the Diameter

The problem is that without *some* guidelines interoperability can be
tricky. Surely we must have some idea of how IPsec would be used with
Diameter, right? Why not spell this out explicitly?

For example, implementations MUST USE encryption, since otherwise we
have no hiding capabilities. Transport mode ESP with non-null transform
seems like a reasonable way to go. In terms of transforms, 3DES seems like
a reasonable thing to implement at least. Remember, DES is still mandatory
within IPsec, but will soon be deprecated. 

Diameter clients and servers are likely to have fixed IP addresses, but
where they don't, then a warning is appropriate against use of pre-shared
keys with Main Mode, since this requires group secrets.

---

From: David Frascone <[email-masked]>
Date: Tue, 26 Feb 2002 16:01:40 -0600

My vote is to leave the details *out* of the draft.

-- 
David Frascone

     If wishes were horses, dogfood would be a lot cheaper.

---

From: David Spence <[email-masked]>
Date: Tue, 26 Feb 2002 18:00:35 -0500

My question would be, Who do we expect to claim conformance to the Diameter
standards?  Certainly not the service providers.  So specifying what a
service provider MUST do to be in compliance seems out of place.  Service
providers would not even expect to read these standards.  So if we are
trying to reach the service providers we should write a BCP on Diameter
security practices.

It is the access device and server vendors who will claim conformance to the
Diameter standards.  For the access device vendors, perhaps including this
material is relevant.  It seems irrelevant, however, to server vendors
unless the server has to actually do something in order to comply.  So my
question is, are we suggesting that a Diameter server should be able to
originate an IKE exchange that would trigger establishment of an IPsec
tunnel?  If so, then we should describe what the real requirements are. 
Under what circumstances would the server take what action and what is the
server required to do if the attempt fails and how does the server verify
that the correct security is in place?  Otherwise, we should put this
material in a BCP rather than the Diameter standards themselves.

---

From: "Jari Arkko" <[email-masked]>
Date: Wed, 27 Feb 2002 05:36:11 +0200

I believe Bernard is right and interoperability is enhanced if
we give specific rules about how IPsec must be used. I think
we should keep the details.

Some small nits though:

- "with a non-null transform" => "with non-null encryption and
  authentication algorithms"

- IKE is a MUST and manual keying is a MUST NOT. I don't
  know, but I'd be able to live with manual keying as well and that
  could be the low-cost solution to some low-cost NASes...
  given that there is a (weak) protection against replay attacks
  through Hop-by-Hop identifier at Diameter layer.

- "...access to locally stored secret ... " this sentence may be
  unnecessary, or?

- "SHOULD check the pertinent Certificate Revocation List (CRL)" =>
  "SHOULD use pertinent certificate revocation checks"? CRLs are
  not the only possible way, so maybe we should make the sentence
  a bit more general as attempted here.

- "... Phase 1 Delete message ..." - Could we leave this paragraph
  out, is it really necessary?
 
Jari

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 26 Feb 2002 19:12:28 -0800 (PST)

The editorial team is struggling mightily to get as many issues as
possible resolved by the March 1, 2002 submission deadline. 

They need your help.

Life as an editor is a *lot* easier if people post proposed text, making
it clear what is to be replaced. That allows the editor to do a simple
"search and replace". One can cycle through quite a few changes rapidly
that way. 

So if you would like a document changed, and haven't submitted an
issue, *please* do so in the prescribed format, with detailed change
recommendations. This helps us track the issue and determine whether it
was resolved or just fell between the cracks. It also helps the
editors get what they need to be most efficient. 

If you are commenting on a proposed resolution, please include your
complete alternative text. That way, the editor doesn't have to wind
through a long thread to piece together what the resolution is -- since
the final message of the thread will presumably have complete text agreed
to by the discussants.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 26 Feb 2002 19:20:30 -0800 (PST)

> Are we suggesting that a Diameter server should be able to
> tunnel? 

Why should a Diameter server (or client for that matter) be establishing
IPsec tunnels? 

> We should describe what the real requirements are. 

I agree. This implies a security considerations section with a threat
model. Better late than never, I guess :(

---

From: David Spence <[email-masked]>
Date: Tue, 26 Feb 2002 23:12:54 -0500

> Why should a Diameter server (or client for that matter) be establishing

I didn't think it would.  But if it doesn't, then it isn't necessary to
specify the IPsec requirements in the Diameter standard because there would
be nothing in those requirements for a Diameter implementation to comply
with.

> model. Better late than never, I guess :(

O.K.  I guess we should cover the operational requirements in the security
considerations section.  We probably don't need to specify specific IPsec
options there except to note the minimal requirements.