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

Re: Comments about draft-ietf-ipsec-ike-01.txt

 

Tero Kivinen wrote:

 
> 6. Modes for IKE Phases
...
> 6.1 Phase 1
...
>    Use of the commit bit from [MSST98] during Phase 1 is forbidden.
>    Implementations SHOULD respond with an notify message whose type is
>    set to INVALID-FLAGS (8).

We should probably add text here saying which identities are allowed
in phase 1. I think the consensus is something like this:

   Phase 1 can only use identities that identify one host or security
   gateway. This includes ipv4/6 address, fqdn, user@fqdn,
   distinguished name, general name and key id. Subnets or ranges are
   not allowed in phase 1.
 
 

As Dan McDonald mentioned, the paragraph should look something like:
  Phase 1 can only use identities that identify a host a security
   gateway or a user. This includes ipv4/6 address, fqdn, user@fqdn,
   distinguished name, general name and key id. Subnets or ranges are
   not allowed in phase 1.
 
>    - Life Type
>
>       seconds                             1
>       kilobytes                           2

Is there any need to have life type of kilobytes in the phase 1? I
don't really think so, but I think there would be use to have

        negotiations                        3

That would limit the number of phase 2 negotiations done over phase 1
isakmp sa. This way you could say that this Isakmp SA is only valid to
negotiate 5 quick mode negotiations, and after that it should be
deleted. The negotiations should be defined so that all negotiations
that use SKEYID_d (consumes entropy from it) is counted as one
negotiation, those negotiations which do not use it (notifications,
new group mode etc) are not counted as negotiations here.
 
 

I'd like to comment that due to the symmetric nature of IKE SA's (an IKE peer can use the same IKE SA for both encryption and decryption),
it seems difficult to enforce a limitation on the number of negotiations or the amount of data encrypted with the IKE SA.
Since packets can get lost (especially notifications) the two IKE peers can get out of sync regarding the number of negotiations they had or the amount of data they encrypted. This can lead to a scenario in which one side thinks that the IKE SA has been out used while the other side thinks it is still valid.
Time restrictions seem to work fine as long as we don't travel at speeds close to the speed of light.
 
Follow-Ups: References: