[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments about draft-ietf-ipsec-ike-01.txt
Here are some comments about the draft-ietf-ipsec-ike-01.txt. I
already talked with Dan Harkins about this issues in the interop, but
I promised to put those issues also here in the list, so others can
comment them.
> IPSEC Working Group Dan Harkins, Network Alchemy
> INTERNET-DRAFT Dave Carrel, Redback Networks
> draft-ieft-ipsec-ike-01.txt May 1999
>
> The Internet Key Exchange (IKE)
> <draft-ietf-ipsec-ike-01.txt>
...
> 1. Abstract
> This memo describes a key exchange and security negotiation protocol
> which is intended to depricate [HC98]. As such it will not change the
> "bits on the wire" for an implementation which is compiant with
> [HC98] but will clarify contentious issues with [HC98] and attempt to
> explain the protocol in a less haphazard manner. Due to advances in
This draft do change some bits on the wire, it for example makes some
previously allowed forms of packets not allowed (isakmp cookies). Also
the DSA signature is defined quite different what people interpreted
from the previous version.
> 3. Introduction
>
> A Domain Of Interpretation defines the attributes (and their
> meanings) negotiated by IKE. It may overload payloads that are
> defined in [MSST98]. This protocol does not define its own DOI per
> se. It does not define DOI nor Situation values for the SA payload
> during Phase 1 negotiation.
>
> The Phase 1 SA MAY use the DOI and situation from a non-ISAKMP
> service (such as [Pip97]). In this case an implementation MAY choose
> to restrict use of the Phase 1 SA for establishment of SAs for
> services of the same DOI. Alternatively, a Phase 1 SA MAY be
> established with the value zero in both the DOI and Situation fields
> and in this case implementations will be free to establish security
What does zero Situation field mean?
1) Use zero length situation field, i.e just leave the whole
situation part away?
2) Put zero in the Situation bitmap, and leave rest away?
3) Something else?
I would really say it means 1 above.
> 3.2 Attribute Negotiation
>
> During security association negotiation Initiators present offers, in
> the form of protection suites, to Responders. Responders MUST NOT
> modify any attributes of any offer (with the possible exception of
> attribute encoding, see Appendix A). If the Initiator of an exchange
> notices that attribute values have been changed or attributes have
> been added or deleted from an offer made that response MUST be
> rejected.
>
> The SA payload from [MSST98] is used to negotiate security
> associations in both Phase 1 and Phase 2 exchanges. This payload
> contains a field for a Security Parameter Index (SPI) and a field for
> the length of the SPI. During Phase 1 the SPI field MUST be empty and
> the length of the SPI MUST be zero. During Phase 2 the SPI values and
> their lengths depends on the particular DOI being negotiated.
This is one of the cases this draft forbids previously allowed use. I
still agree that this change is one we should make, but we probably
should add some comment in the text about this.
> Diffie-Hellman groups are specified either using a defined group
> description (section 5) or by defining all attributes of a group
> (Appendix A) in a protection suite. Group attributes, such as group
> type or prime number MUST NOT be offered in conjunction with a
> previously defined group, defined either in section 5 or via a
> previous New Group Mode exchange (section 6.3).
One question about this. Is implementation allowed to define new
groups on the fly? I.e include both private group number, and
parameters, so this would do implicit new group mode and add that
newly defined group with the group number given? If this is allowed I
think it should be explicitly said here.
> Certain negotiable attributes have ranges or multiple acceptable
> values. For instance, if the policy specification on a peer mandates
> group 2 but is offered group 5, as part of an otherwise acceptable
> protection suite, the peer SHOULD accept that value as it provides
> more security than demanded. SA lifetimes pose similar issues. If a
> peer has a local policy which requires SAs live for no more than 2
> hours and is offered a protection suite which contains a lifetime
> value of 1 hour, the peer SHOULD accept that value as it provides
> less opportunity for key exposure.
I think it would be more understandable if the text above would say
something like this:
Certain negotiable attributes have ranges or multiple acceptable
values. Examples of that kind of attributes are the group
descriptor, key length and lifetimes. Implementations SHOULD
allow defining acceptable ranges for those attributes, i.e
it SHOULD be possible to configure system to allow groups 2, 4, and
5, or to accept key lengths between 128 and 448 bits.
This what this issue is really about. Current implementations have
quite often very limited configuration, and they don't allow doing
that kind of configurations. If the policy says use only group 2 there
is really no use to force him to use group 5, but there should be
option to allow saying use group 2 or 5.
We can also leave this whole thing out and say it is an implementation
issue, and not a protocol issue, thus this kind of thing doesn't
belong here...
> 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.
> 6.1.1.2 Main Mode Authentication with Digital Signatures
...
> In general the signature will be directly over I-digest and R-digest
> which are generated by the pseudo-random function. However, this can
> be overridden for construction of a signature if the signature
> algorithm is tied to a particular hash algorithm by changing the
> digest construction from:
>
> digest = prf(key, msg)
>
> to
>
> digest = hash(key | msg)
>
> For example, DSS is only defined with SHA's 160 bit output and in
> this case the digests would be:
>
> I-digest = SHA(SKEYID | g^i | g^r | CKY-I | CKY-R | SAi_b |
> ID_i1_b)
>
> R-digest = SHA(SKEYID | g^r | g^i | CKY-R | CKY-I | SAi_b |
> ID_r1_b)
>
> The contents of the signature payload would then be the resulting
> 320-bit DSA signature of the digest ("r" followed by "s").
This is quite different than was in the previous draft, and I think
most of the implementations are using this kind of definition:
Sign(hmac-sha(SKEYID, g^i | g^r | CKY-I | CKY-R | SAi_b | ID_i1_b))
> 6.1.1.3 Main Mode Authentication with Public Key Encryption
...
We should probably add there paragraph either allowing using CERT
payloads in the public key encryption (with a warning that it breaks
identity protection, because they must be sent clear), or disallow
using them (because they break identity protection).
> 6.2 Quick Mode
...
> In the case of a Quick Mode Initiator, these client IDs are be
> supplied by the service requesting SAs. In the case of a Quick Mode
> Responder, those IDs are extracted from the Quick Mode message and
> supplied to the service identified by the DOI value in the SA payload
> (also in the Quick Mode message). If the identities are not
> acceptable to the service (due to policy or other reasons), an
> Informational message containing a notify payload, with a type of
> INVALID-ID-INFORMATION (18), SHOULD be sent back to the Initiator.
> The Responder MUST NOT modify the client IDs in any way and they MUST
> be delivered back to the Initiator in exactly the order supplied,
> that is, IDi2 does not become IDr2 in the message the Responder sends
> back to the Initiator.
Here should again be some kind of paragraph about acceptable identity
types (only those which can be mapped to ip address or ip addresses
(ranges, subnets)). I don't think there is any meaning giving out
user@fqdn, fqdn, distinguished name, or general name as a proxy
identity? Key id should probably be allowed, so people can use that as
"policy key id" to their own policy database and fetch the real proxy
information from the policy database.
> 6.3 New Group Mode
...
> New Group Mode MUST NOT be used prior to establishment of an IKE SA.
> The description of a new group MUST only follow phase 1 negotiation.
> (It is not a phase 2 exchange, though).
>
> Initiator Responder
> ----------- -----------
> HDR*, HASH(1), SA -->
> <-- HDR*, HASH(2), SA
>
> where HASH(1) is the prf output, using SKEYID_a as the key, and the
> message-ID from the ISAKMP header concatenated with the entire SA
^^
> proposal, body and header, as the data; HASH(2) is the prf output,
^^^^^^^^
I think we should say "rest of the packet" instead of only the SA
proposal. This way if we add later notifications or something in the
same packet those payloads will also be authenticated.
> Groups may be directly negotiated in the SA proposal with Main Mode.
> To do this the component parts-- for a MODP group, the type, prime
> and generator; for a EC2N group the type, the Irreducible Polynomial,
> Group Generator One, Group Generator Two, Group Curve A, Group Curve
> B and Group Order-- are passed as SA attributes (see Appendix A).
> Alternately, the nature of the group can be hidden using New Group
> Mode and only the group identifier is passed in the clear during
> phase 1 negotiation.
This would indicate that we can give "group number" to the private
group negotiated in the phase 1, and use that group then in the phase
2.
> 6.4 Notification Exchanges
> 6.4.2 Acknowledged Informational
>
> IKE exchanges are sent as ISAKMP messages whose delivery is
> unreliable. This fact has been taken into account in the design of
> Phase 1 and Phase 2 exchanges since retransmission timers are set to
> allow for packet loss. Due to the unreliable nature of the exchange
> described in 6.4.1 certain messages should not be sent that way. For
> instance, if a notification that an SA has been deleted is lost the
> sender may delete it but the intended recipient will have not way of
> knowing this fact.
>
> The first payload of the acknowledged Informational exchange MUST be
> a hash payload and the second payload MUST be the nonce of the
>
> Harkins Carrel [Page 29]
>
> INTERNET DRAFT May 1999
>
> sender. The Responder MUST NOT change the notification payloads
> which follow the Initiator's nonce.
>
> The acknowledged Informational exchange is defined as:
>
> Initiator Responder
> ----------- -----------
> HDR*, HASH(1), Ni, N/D -->
> <-- HDR*, HASH(2), Nr, N/D
>
> where HASH(1) is prf output using SKEYID_a from the Phase 1 SA
> identified by the cookies in the ISAKMP header as the key, and the
> unique, pseudo-random message ID for this exchange concatenated with
> the remaining payloads (in this case, a delete or notify and a nonce
> payload, but more payloads could be chained to this message) as the
> data, and HASH(2) is the prf output using SKEYID_a, from the Phase 1
> SA identified by the cookies in the ISKAMP header, as the key and the
> nonce payload sent by the Initiator concatenated with the pseudo-
> random message ID for this exchange and the remaining payloads as the
> message to hash. The hashes for the above exchange would be:
>
> HASH(1) = prf(SKEYID_a, M-ID | Ni | N/D)
> HASH(2) = prf(SKEYID_a, Ni | M-ID | Nr | N/D)
>
> This memo does not proscribe which messages should be sent with the
> Acknowledged or Unacknowledged Informational.
I would really like to see two new kind of notifications here:
Initiator Responder
----------- -----------
HDR, SIG, [CERTs], Ni, N/D -->
Where SIG (MUST be first payload) is signature of the HASH of the rest
of the payload. This would allow sending delete and error notification
payloads to the responder even when we do not have ISAKMP SA up yet
(for example sending error message of phase 1 (NO-PROPOSAL-CHOSEN)).
In this case the SIG should also define the HASH algorithm to use, so
we should either use signature format that contains it or define it
somewhere else.
> 8 Security Considerations
> The strength of a key derived from a Diffie-Hellman exchange using
> any of the groups defined here depends on the inherent strength of
> the group, the size of the exponent used, and the entropy provided by
> the random number generator used. Due to these inputs it is difficult
> 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
> sufficient to use for 3DES. Groups three through five provide
160 bits is not sufficient for 3DES. According the previous version it
was sufficient to the DES... Oakley says:
----------------------------------------------------------------------
The modulus size alone does not determine the strength of the
Diffie-Hellman calculation; the size of the exponent used in
computing powers within the group is also important. The size of the
exponent in bits should be at least twice the size of any symmetric
key that will be derived from it. We recommend that ISAKMP
implementors use at least 180 bits of exponent (twice the size of a
20-year symmetric key).
----------------------------------------------------------------------
So assume 2 * 112 = 224 bits is minimum for 3DES.
...
> Optimal Asymmetric Encryption Padding [BR94] MUST be used with PKCS#1
> to avoid the adaptive chosen ciphertext attack against RSA that is
> described in [Ble98]. See [PKCS1].
>
> The acknowledged Informational exchange is open to replay attacks.
There should also be comment here, that main mode (identity
protection) is open to man in the middle attack, that will reveal
initiators identity.
> Appendix A
> - Hash Algorithm Defined In
> MD5 1 RFC 1321
> SHA 2 FIPS 180-1
> Tiger 3 See Reference [TIGER]
Ripemd160 should be added here. Also we should define the length of
the tiger meant here. The referenced paper defines Tiger/192,
Tiger/160 and Tiger/128. Just changing that line to
> Tiger/192 3 See Reference [TIGER]
Would solve the issue.
> - 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.
> The key for DES-CBC is derived from the first eight (8) non-weak and
> non-semi-weak (see Appendix A) bytes of SKEYID_e. The IV is the first
> 8 bytes of the IV material derived in section 4.1 above.
What does the above mean? If the bytes 0-7 are weak do we take bytes
1-8 or 9-15? I assume it is bytes 1-8 (this is how we implemented it).
--
kivinen@iki.fi Work : +358-9-4354 3218
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
Follow-Ups: