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

IBM VPN Bakeoff Issues



Roy Pereira writes:
> 4. The size of SPIs in NOTIFY messages is ambiguous.  Some vendors send zero
> bytes while others send 16 bytes.  We need to clarify the wording in the
> documents.

This depends on the notify messages. In status notifications that are
send during Phase I negotiation along with other Phase I payloads may
contain SPI size 0, but those Phase I notifications that are send
after Phase I (delete, errors, initial contact sent as separate
informational exchange to authenticate it etc), must have valid SPI
(16 bytes, containing cookies) so the responder might find out the
related ISAKMP SA.

There is also some problems when sending error notifications back when
using new group mode or configuration mode. For those exchanges there
is no SPI field that could be used to identify the negotiation where
this error message belongs.

I would suggest that we add text saying that if in the notification
payload the Protocol-ID is 0 (==PROTO ISAKMP) then the SPI size may be
either 4 or 16. If the SPI size is 4 then the SPI field contains the
MESSAGE-ID of the negotiation under the current ISAKMP SA (seen from
the cookies of the packet) to whom this error/status notification
belongs. If the SPI size is 16 then the SPI field contains cookies of
the ISAKMP SA to whom this error/status notification belongs.

This allows sending authenticated error notifications to other ISAKMP
SAs than current one (for example the invalid cookie notification,
which might be sent using different ISAKMP SA, because we have already
deleted the ISAKMP SA the other end is trying to use). And it also
allows sending errors to configuration mode and new group mode
exchanges by just using the message id of those exchanges as a key.

For quick modes this really isn't so much problem because we usually
have SPI in the SA. Of course if we want to return error because we
couldn't parse the SA proposal sent by the other host we cannot use
SPI. Also if we have proposals that don't have SPI (IPCOMP?) we might
want to use the message-id approach.

Also because one SA proposal may contain multiple SPIs, it might be
easier to use message-ids always to simplify finding the proper quick
mode negotiation when notification is received (currently the SPI may
be any of the SPIs inside the SA proposal).

> 6. What SPI should be sent in a DELETE message?  Some vendors send zero
> sized SPI, some send 16 bytes of SPI.

Here I think we should always send 16 bytes of SPI, because we might
want to use different ISAKMP SA to send that DELETE message instead
the one we are deleting. So we cannot use the initiator and responder
cookies to specify the sa to be deleted. 

> 14. Is proposing "RC5 with 128 bit key length" the same as proposing "RC5"
> since 128 bits is the default key size?  Should vendor's be aware of the
> default key size and equate comparable cipher/key sizes?

If you mean that if the responder is allowed to remove key length
attribute because it has default value, or add key length attribute
with default value when sending back selected sa information, then the
draft is quite clear (dratf-ietf-ipsec-isakmp-oakley-08.txt):

----------------------------------------------------------------------
   for potential security associations to responders. Responders MUST
   NOT modify attributes of any offer, attribute encoding excepted (see
   Appendix A).  If the initiator of an exchange notices that attribute
   values have changed or attributes have been added or deleted from an
   offer made, that response MUST be rejected.
----------------------------------------------------------------------

You are not allowed to modify the SA proposal... 

> 17. The HASH payload must be the first payload in a info/new group exchange.
> This isn't clear in the documents.

For new group mode we should just add "In New Group Mode, a HASH
payload MUST immediately follow the ISAKMP header", for Informational
Exchanges we also have to add something for the cases when we don't
have HASH because we dont have ISAKMP SA yet. So something like "In
Informational Exchanges, a HASH payload (if present) MUST immediately
follow the ISAKMP header". 

> 20. It would be nice if Delete messages supported multiple protocols instead
> of just one protocol.  This is handy for deleting SA bundles.

There is nothing in the draft that says each informational exchange
must only contain one delete payload, so when you want to delete a SA
bundle you could just send informational exchange having

HDR*, HASH(1), D, D, D ...

and each of those Delete payloads will delete one protocol. Hash is
again calculated just like in the normal case, message id followed by
the rest of the packet. 

> 22. We need further clarification on when Notify messages start becoming
> encrypted.  Some vendors start encrypting after message 4 of MainMode, some
> wait until phase 1 complete.

Because the IV calculation of the encrypted Notify message needs "last
phases 1 CBC output block", and if that hasn't been received/sent
already then we cannot calculate IV, thus we cannot use authenticated
notifications. 

> 24. Someone pointed out that the same DH group has to be used for all
> proposals when using Aggressive Mode and Quick Mode.

The draft-ietf-ipsec-isakmp-oakley-08.txt says:
----------------------------------------------------------------------
   Security Association negotiation is limited with Aggressive Mode. Due
   to message construction requirements the group in which the Diffie-
   Hellman exchange is performed cannot be negotiated. In addition,
----------------------------------------------------------------------

and

----------------------------------------------------------------------
   All offers made during a Quick Mode are logically related and must be
   consistant. For example, if a KE payload is sent, the attribute
   describing the Diffie-Hellman group (see section 6.1 and [Pip97])
   MUST be included in every transform of every proposal of every SA
   being negotiated. Similarly, if client identities are used, they MUST
----------------------------------------------------------------------

So I think that is already covered in the draft. 

> 25. Someone pointed out that the ID payload is redundant if we are doing
> RSA_SIG authentication, since the certificate already has the identity.

If I send you 10 certificates forming a chain, which of those is the
one that contains the end user identity? The first? The second? The
last? Identity payload is NOT redundant even in RSA signature
authentication in case we are having more than one certificates
involved. Also the certificate payloads are optional, so the other end
might not send anything.

> 26. We need clarification on the SPI usage in phase 1's SA payload.  The
> documents state it can have 0-16 bytes.

The draft-ietf-ipsec-isakmp-10.txt says:
----------------------------------------------------------------------
During phase 1 negotiations, the initiator and responder cookies deter-
mine the ISAKMP SA. Therefore, the SPI field in the Proposal payload is
redundant and MAY be set to 0 or it MAY contain the transmitting entity's
cookie.
----------------------------------------------------------------------

And I really think that it should be changed to allow only one choice.
Either modify that to say:

----------------------------------------------------------------------
During phase 1 negotiations, the initiator and responder cookies deter-
mine the ISAKMP SA. Therefore, the SPI field in the Proposal payload is
redundant and its size MUST be set to 0.
----------------------------------------------------------------------

or add similar paragraph to the draft-ietf-ipsec-isakmp-oakley-08.txt
draft.

There is also another paragraph in the draft-ietf-ipsec-isakmp-10.txt
saying (proposal payload):

----------------------------------------------------------------------
 o  SPI Size (1 octet) - Length in octets of the SPI as defined by the
    Protocol-Id.  In the case of ISAKMP, the Initiator and Responder
    cookie pair from the ISAKMP Header is the ISAKMP SPI, therefore, the
    SPI Size is irrelevant and MAY be from zero (0) to sixteen (16).  If
    the SPI Size is non-zero, the content of the SPI field MUST be
    ignored.  If the SPI Size is not a multiple of 4 octets it will have
    some impact on the SPI field and the alignment of all payloads in the
    message.  The Domain of Interpretation (DOI) will dictate the SPI
    Size for other protocols.
----------------------------------------------------------------------

so that should be modified accordingly. Allowing the cookie to contain
anything from 0 to 16 bytes is just useless, and cause
interoperability problems. Having useless choices in cases where we
dont need them just adds complexity of the protocol. 

> 27. Vendors should be aware of different IKE version numbers.  Currently
> v0.1 and v1.0 are defined.  The text needs to be clearer on version numbers.

I sent some email about this already earlier, see that for my
comments. 

> 31. Do we allow CertReq payloads in shared-secret mode?  Yup, but you
> probably don't want to reply back with a certificate.

The draft-ietf-ipsec-isakmp-10.txt says:
----------------------------------------------------------------------
ing the exchange.  The responder to the Certificate Request payload MUST
send its certificate, if certificates are supported, based on the values
contained in the payload.  If multiple certificates are required, then
----------------------------------------------------------------------

so if you support certificates you MUST send it even in shared-secret
mode... 

> 32. Should proposal rank number start with 1 or zero and should they
> increase by 1 ?

I would say that there is no reason to limit them to start from any
specific number or to increase by 1, so I would say we should add some
more clarifying text to the draft-ietf-ipsec-isakmp-10.txt.

> 34. What should the maximum number of proposals be?  Some vendors only
> handled a limited number of proposals.

I would set this to quite large (128? 256?) value, because the other
end might not know before hand what kind of limited version the other
end has and might want to offer all possible combinations it supports
for maximal interoperability (and if the other end limits numbers of
proposal to some very small number like 16, then when the initiator
tried to be as interoperative as possible, caused them not to
interoperate).
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/


References: