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

From: Bernard Aboba <[email-masked]>
Date: Sat, 29 Dec 2001 08:36:31 -0800 (PST)

Submitter: Bernard Aboba <[email-masked]>
Date: December 28, 2001
Type: Technical
Document: Base -08
Section: 2.2
Rationale:
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."