Subject: [IPsec] IKEv1 Identification payload processing

From: "balaji raghavan" <[email-masked]>
Date: Thu, 14 Aug 2008 10:13:03 +0200

Hi,

I have one question regarding IKEv1.  How is an IKE peer expected to
respond to a peer identification failure ?
i.e more specifically If it chooses to send a notification what is the
notify message type should it send ?

RFC 2408 sections 4.3,4.4,4.6 state the following in case of errors in
ID payload exchanges:

"  One possible action is the transmission of a Notify payload as part
   of an Informational Exchange. "

There is section 5.8 in rfc2408 which sheds more light on what to do
if the ID type is unsupported
but can this section be extrapolated to specify behaviour in the case
of an unacceptable ID ?

ie it " may " send a INVALID-ID-INFORMATION notification to the peer.
or is any other notification also an acceptable reply ( for example
NO-PROPOSAL-CHOSEN ) ?

---SNIP------
RFC2408 5.8:
When an Identification payload is received, the receiving entity
(initiator or responder) MUST do the following:
1. Determine if the Identification Type is supported. This may be
based on the DOI and Situation. If the Identification
determination fails, the message is discarded and the following
actions are taken:
(a) The event, INVALID ID INFORMATION, MAY be logged in the
appropriate system audit file.
(b) An Informational Exchange with a Notification payload
containing the INVALID-ID-INFORMATION message type MAY be
sent to the transmitting entity. This action is dictated by
a system security policy.
---SNIP------

And finally:

RFC 4309:  Has the following text for identification failures in quick
mode exchanges.

"Local policy will dictate whether the proposals are acceptable for
the identities
specified.  If the client identities are not acceptable to the Quick
Mode responder
(due to policy or other reasons), a Notify payload
 with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent."

Does this apply to identification failures in other exchanges as well ?

-Best Regards
Balaji Raghavan
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Thu, 14 Aug 2008 11:23:53 +0300

INVALID-ID-INFORMATION is very specific. It implies that the peer does  
not accept this *type* of identification payload.

Sending it for an ID that is just not authorized (most commonly: user  
not defined) is (a)lying and (b)can lead to user enumeration attacks.

I think the safe choice is AUTHENTICATION_FAILED (24)

On Aug 14, 2008, at 11:13 AM, balaji raghavan wrote:

> Scanned by Check Point Total Security Gateway.
>