[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Clarification on ISAKMP Informational Exchange



We've come up with these questions as we beef up Notify and Delete in our
implementation, and I give answers that seem logical to me; could an
authoritative voice please say what's required on these points?

Can a Notification or Delete Payload appear other than in an Informational
Exchange?

    Apparently not, because ISAKMP states that an exchange prescribes all
    the messages and all the payloads which are allowed, and none of the
    exchanges prescribe that Notify or Delete may appear within them.

    Most particularly: if you want to Notify for failure in Phase I,
    apparently you should make a new Informational Exchange with Message
    ID zero.

Can one send/receive an unencrypted Informational Exchange?

    Apparently so, for Phase I, since Notifications are explicitly allowed
    for the earliest Phase I failures.

Can a Phase I Informational Exchange be encrypted?

    Apparently so, since one could after the Keys have been exchanged.

    But it seems it is not required at that point, because the spec only
    demands protection for an Informational Exchange after a Phase I
    SA has been fully established.

    Note that if the Initiator doesn't like the Responder's message which
    sends KE in Phase I, the Initiator would send an unencrypted Notify
    but the Responder might believe the message must be discarded for
    not being encrypted, because it has established keys.  [A smarter
    Responder would know at this point that key establishment is still
    provisional pending getting anything positive from the other.]

Must a party make a new exchange: new cookies, and new message ID if
applicable, for every different time it needs to send an informational
message?

    New message ID (for Phase II): sure, it won't kill me. But, why
    bother, what's the point?

    New cookies: I presume no; It would raise difficulties, and be
    counterproductive, to put any new cookie in the message, because the
    cookie would not relate to anything the receiver has, and cannot
    be checked in any way.

    It seems to be demanded, but the justification stated is problematic,
    in "2.5.3 Anti-Clogging Token (``Cookie'') Creation":

        The details of cookie generation are implementation dependent, but
        MUST satisfy these basic requirements (originally stated by Phil
        Karn in [Karn]):
        [ . . . ]
        ISAKMP requires that the cookie be unique for each SA establishment,
        Notify, and SA Delete to help prevent replay attacks, therefore,
        the date and time MUST be added to the information hashed.

    Problem is: it claims new cookies will protect a Notify or Delete sent
    in an Informational Exchange.  But how can it, since the one who
    receives the message has not sent a new cookie and so cannot verify
    the sender's liveliness?