[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Some comments to draft-ietf-ipsec-ikev2-00.txt
> The Internet Key Exchange (IKE) Protocol
> <draft-ietf-ipsec-ikev2-00.txt>
I think this draft has done good job of combining the tree rfcs
together, and I think this is one step in to the right direction. I
have just finished reading this, sigma and jfk, and this seems to be
only one that is ready enought that I can comment it.
> 2.2 Use of Sequence Numbers for Message ID
...
> In the case where the IKE_SA_init is rejected (e.g. in order to
> require a cookie), the second IKE_SA_init message will begin the
> sequence over with Message #0.
I assume it is also reset to zero every time the IKE SA is rekeyed
using the create-child-sa for the IKE SA?
> 3 The Phase 1 Exchange
...
> HDR*, ID, AUTH, [CERT,]
> SA, TSi, TSr -->
Are the SA, TSi, TSr mandatory in each Phase 1 exchanges? Accordingly
to the diagram they seems to be, but I think there are cases
where we want to only create the IKE SA and not to create any IPsec
SAs yet. One example would be pre-generating IKE SA between two hosts
on boot, and keep that up all the time.
Also can the phase 2 SA creation included in this message also include
PFS, i.e can there also be KEi and KEr payloads?
If I read correctly from the draft only payloads that has any
kind of ordering restrictions are TSi and TSr payloads. I would really
like to remove that ordering restriction too, i.e modify the payloads
so that they itself identify which payload they are.
Just a side note, that in road warrior cases the normal TSi and TSr
are going to be the traffic selectors for the DHCP over ipsec SA which
ise used to the get the internal ip address for the host.
> 3.1 Generating Keying Material for the IKE-SA
...
> SKEYSEED = prf(Ni | Nr, g^ir)
As this is the only place where nonces are used their entropy is
limited to the output of the PRF. I.e it is no use of using nonces
whose combined entropy is more than 128 bits if we using the HMAC-MD5
as PRF, as the output of the SKEYSEED is going to be 128 bits.
> SKEYSEED_d = prf(SKEYSEED, g^ir | CKY-I | CKY-R | 0)
> SKEYSEED_a = prf(SKEYSEED, SKEYSEED_d | g^ir | CKY-I | CKY-R | 1)
> SKEYSEED_e = prf(SKEYSEED, SKEYSEED_a | g^ir | CKY-I | CKY-R | 2)
I think that could be fixed by adding the nonces to the above
calculations also in addition of the cookies.
> 4 The CREATE-CHILD-SA (Phase 2) Exchange
...
> The CREATE_CHILD_SA response contains:
>
> <-- HDR*, SA, Nr, [KEr,]
> TSi, TSr
>
> The Responder replies (using the same Message ID to respond) with the
> accepted offer in an SA payload, optionally a Diffie-Hellman value in
> the KE payload, and the traffic selectors for traffic to be sent on
> that SA in the TS payloads, which may be a subset of what the
> Initiator of the child-SA proposed.
If I understand correctly the initiator cannot force responder to use
PFS, i.e to send its own KEr payload as it is optional and the group
selectors inside the SAs only identify the type of group used in the
KEi payload. Is this correct?
Also those diagrams above does not indicate that there can be ID
payload included in the phase 2 exchange (accordingly to 7.5 it can be
included there). I think it would be better to include optional
payloads also in to the packet flow pictures. Or at least have
appendix listing complete exchange including all optional payloads in
all possible packet where they can exists.
> 7 Header and Payload Formats
>
> 7.1 The IKE Header
>
> IKE messages use UDP port 500, with one IKE message per UDP datagram.
> Information from the UDP header is largely ignored except that the IP
> addresses from the headers are reversed and used for return packets.
If we want to get NAT-T (NAT Traversal) to work using IKEv2 we also
need to reverse ports, the source port is NOT going to be port 500,
thus the reply MUST be sent back to the original source port of the
incoming packet. This also means that both ends must remember the
destination port number associated with the IKE SA.
> 7.3.1 Proposal Substructure
Proposal and transform substructures are missing the criticality flags
included in all other generic payload headers. I think it would be
better to have only one generic payload header format...
> o SPI Size (1 byte) - During phase 1 negotiation this field
> MUST be zero. During phase 2 negotiation it is equal to the
> size, in bytes, of the SPI of the corresponding protocol
> (4 for ESP and AH, 2 for IPcomp).
SPI size can also be 8 bytes in case this is the IKE SA rekeying. The
new IKE SA needs cookies that needs to be specified here (as said in
the 4.2).
> o SPI (variable) - The sending entity's SPI. Even if the SPI
> Size is not a multiple of 4 bytes, there is no padding
> applied to the payload. When the SPI Size field is zero,
> this field is not present in the Security Association
> payload. This case occurs when negotiating the IKE-SA.
That case does not occur in case of the IKE SA rekey.
> o Proposal # (1 byte) - Identifies the immediate proposal. The
> first proposal has the number of one (1) and each subsequent
> proposal has a number which is one greater than the last.
>
> o Proposal Length (2 bytes) - Length in bytes of the proposal
> including all SA Attributes.
>
> o SA Attributes (variable length) - This field contains SA
> attributes for the immediate transform. The SA Attributes
> MUST be represented using the Transform Attributes format
> described below.
>
> o RESERVED (1 byte) - MUST be sent as zero; MUST be ignored.
These entries here are some extra junk. Some of those fields ware
already explained earlier and some of those fields do not exists at
all.
> 7.3.2 Transform Substructure
...
> o Transform-ID (2 bytes) - The specific instance of the transform
> type being proposed.
Transform-ID is specified to be 2 bytes (16 bits), but all numbers
assume it to be only 8-bits. I.e all ranges below end at 255 instead
of 65535:
> values 12-240 are reserved to IANA. Values 241-255 are for
> private use among mutually consenting parties.
...
> For Transform Type 3 (Authentication Method), defined Transform-IDs
> are:
>
> Name Number Defined In
> RESERVED 0
> Methods in IKEv1 1 - 5 (RFC2409)
> Authenticated Diffie-Hellman 6 (this memo)
Why do we need methods for IKEv1 here? This is in completely separate
place compared to the IKEv1, so compability cannot be the issue,
especially when none of the numbers defined by the IKEv1 are not used
here (and I don't assume any of the numbers are going to be used).
> For Transform Type 7 (Window Size), the Transform-ID specifies the
> window size a peer is contracting to support to handle overlapping
> requests (see section 2.3).
One thing that is missing is the negotiation of the
tunnel/transport/UDP-encapsulated-tunnel/UDP-encapsulated-transport
mode. Also RFC2407 allows negotiation of the key rounds, which is
missing from the attributes from the appendix.
> 7.6 Certificate Payload
...
> o Certificate Encoding (1 byte) - This field indicates the type
> of certificate or certificate-related information contained
> in the Certificate Data field.
>
> Certificate Encoding Value
> -------------------- -----
> NONE 0
> PKCS #7 wrapped X.509 certificate 1
> PGP Certificate 2
> DNS Signed Key 3
> X.509 Certificate - Signature 4
> X.509 Certificate - Key Exchange 5
> Kerberos Tokens 6
> Certificate Revocation List (CRL) 7
> Authority Revocation List (ARL) 8
> SPKI Certificate 9
> X.509 Certificate - Attribute 10
> RESERVED 11 - 255
Ok, can someone explain me again what is the X.509 Certificate - Key
Exchange. If it still means the encryption capable key then I think we
can either rename it or remove it as we do not need any encryption
capable keys anymore (no public key encryption modes).
It would be simplier to have only one number allocated for the X.509
keys.
> 7.7 Certificate Request Payload
...
> The Certificate Request Payload is processed by inspecting the "Cert
> Encoding" field to determine whether the processor has any
> certificates of this type. If so the "Certification Authority" field
> is inspected to determine if the processor has any certificates which
> can be validated up to the specified certification authority. This
> can be a chain of certificates. If a certificate exists which
> satisfies the criteria specified in the Certificate Request Payload
> it MUST be sent back to the certificate requestor; if a certificate
> chain exists which goes back to the certification authority specified
> in the request the entire chain MUST be sent back to the certificate
> requestor. If no certificates exist then no further processing is
I think the "MUST" above is little too much. I would say "it MUST
sends its own certificate, and it SHOULD send as much of the
certificate chain it has". Long certificate chains just cause the IKE
packets to be bigger thus causing fragmentation which then causes
other problems.
Also the common problem case in the IKEv1 should be documented here,
i.e what the empty certificate request means or is it forbidden?
> 7.10 Notify Payload
...
> o Notification Data (variable length) - Informational or error data
> transmitted in addition to the Notify Message Type. Values for
> this field are message specific, see below.
Why not using the same encoding that is defined in the
draft-ietf-ipsec-notifymsg-04.txt? It makes some things much easier...
For example the textual error message can be very usefull when it says
that your "authentication failed, because the certificate you provided
could not be verified because the crl for the CA could not be
fetched".
> INVALID-MESSAGE-ID 9
>
> Sent when either an IKE MESSAGE-ID more that ten greater
^^^
I assume that should say negotiated window size.
I think following three messages overlap:
> INVALID-KEY-INFORMATION 17
>
> The KE field is the wrong length. This can occur where there
> is no error if the Initiator guesses incorrectly which
> Diffie-Hellman group the Responder will accept.
> Notification data contains the Transform Substructure
> describing the chosen Diffie-Hellman group.
...
> IKE-SA-INIT-REJECT 32
>
> This notification is sent in an IKE-SA-RESPONSE to request
> that the Initiator retry the request with the supplied
> cookie (and optionally the supplied Diffie-Hellman group).
> This is not really an error, but is processed like one in
> that it indicates that the connection request was rejected.
> The Notification Data, if present, contains the Transform
> Substructure describing the preferred Diffie-Hellman group.
>
> INVALID-KE-PAYLOAD 33
>
> This error indicates that the KE payload does not match the
> chosen Diffie-Hellman group. It can occur legitimately in
> either Phase 1 or Phase 2 if the Initiator supports multiple
> Diffie-Hellman groups and incorrectly anticipates which one
> the Responder will choose.
If the KE payloads and the first group does not match which one of
them to send? If it is first packet and we want to have cookie
exchange then we send IKE-SA-INIT-REJECT, but otherwise we can send
either INVALID-KEY-INFORMATION or INVALID-KE-PAYLOAD. I think we only
need one...
> SINGLE-PAIR-REQUIRED 34
>
> This error indicates that a Phase 2 SA request is
> unacceptable because the Responder requires a separate SA
> for each source / destination address pair. The Initiator is
> expected to respond by requesting an SA for only the
> specific traffic he is trying to forward.
This is usefull, but it would need the granularity level (i.e is it
per-host or per-protocol or per-port which is required by the
responder).
> 7.11 Delete Payload
>
> The Delete Payload, denoted DEL in this memo, contains a protocol-
^^^
Actually I think it is D elsewhere in the document.
> o Protocol-Id (1 byte) - Must be zero for an IKE-SA, [] for
> ESP, [] for AH, and [] for IPcomp.
I think there is something missing above ([])?.
> 7.13.1 Traffic Selector Substructure
...
> TS_IPV4_ADDR_SUBNET 4
>
> An IPv4 subnet represented by a pair of four (4) byte
> values. The first value is an IPv4 address. The second is
> an IPv4 network mask. Note that ones (1s) in the network
> mask indicate that the corresponding bit in the address is
> fixed, while zeros (0s) indicate a "wildcard" bit.
...
> TS_IPV6_ADDR_SUBNET 6
>
> An IPv6 subnet represented by a pair sixteen (16) byte
> values. The first value is an IPv6 address. The second is
> an IPv6 network mask. Note that ones (1s) in the network
> mask indicate that the corresponding bit in the address is
> fixed, while zeros (0s) indicate a "wildcard" bit.
I think it would be better to change the format of subnet selectors to
be IPVx_ADDRESS + Number of bits in the mask. It would remove the
problems what to do when the other end proposes mask 0xff00ff00?
(According to above it is completely valid :-)
> 9 Security Considerations
...
> to determine the strength of a key for any of the defined groups. The
> default Diffie-Hellman group (number two) when used with a strong
> random number generator and an exponent no less than 160 bits is
Is the group 2 still the "default" group?
> Appendix A
>
> Attribute Assigned Numbers
>
> class value type
> --------------------------------------------------------------
> RESERVED 0-5
> Group Prime/Irreducible Polynomial 6 V
> Group Generator One 7 V
> Group Generator Two 8 V
> Group Curve A 9 V
> Group Curve B 10 V
> RESERVED 11-13
> Key Length 14 B
> Field Size 15 B
> Group Order 16 V
> Block Size 17 B
As I said earlier this is missing some of the attributes defined int
he IPsec DOI...
--
kivinen@ssh.fi
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
Follow-Ups: