[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SOI QUESTIONS: 3.4, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7
> 3.4 Preferred ID for responder
> 3.4.A) In JFK and IKEv2, the initiator can include a payload is an
> indication to the responder as to what identity (and corresponding key
> material) the responder should use to authenticate to the initiator. In
> JFKr and IKEv2, this value is encrypted in message 3; in JFKi, it is sent
> in the clear in message 1, thereby allowing a passive attack on the
> responder's likely identity. Is it important to encrypt this identity?
If it is going to used as server-id / virtual-host-id then it should
encrypted. This causes that we cannot make policy decisions based on
that identity, but for IKEv2 that doesn't really matter as the policy
decisions done before that affect the phase 1 SA only, the IPsec SA
can do decisions based on the "you tarzan" message.
> 4. One or two phases
> 4.1 Control channel vs. separate protocols
> 4.1.A) [Meta question, that will be answered by the other questions in
> section 4.] Does SOI need a control channel for SA management? Or is
> it acceptable to piggy back SA management as a part of other parts of
> the SOI protocol?
I think we do need control channel.
> 4.2 Creating multiple SAs for a single pair of entities
> 4.2.A) How important is it that SOI be able to create multiple SA's
> between a pair of entities "cheaply"?
I think there are multiple different scenarios where it is needed. One
that hasn't yet been mentioned is the multi-user unix host running per
user authenticated IPsec connections out. This means that in IKEv2
there needs to be Phase 1 SA for each user, and as the implementation
might not support username as a IPsec selector, it might want to
create new IPsec SA for each TCP/IP port pair the user is using (i.e
when user starts new TCP/IP connection that port pair is added to the
policy and tied to the this phase 1 SA). This requires fast IPsec SA
setups.
One of the requirements is also that IF we are going to support legacy
authentication the creation of the new IPsec SA or rekeying existing
SA SHOULD not require reauthentication of the user, because that
authentication step might need for example typing in password or
secure id code etc. If you have rekey limit of 100 MB and you are
transferring data over 100 MBit/s ethernet you do not want to type in
password every 10 seconds...
> 4.2.B) How often will usage scenarios of SOI need to generate multiple
> SA's between a single pair of entites?
In some scenarios almost always...
> 4.3 Dead peer detection
> 4.3.A) Both JFK and IKEv2 provide dead peer detection via a
> "keep-alive" mechanism. The functionality provided is roughly
> identical. Does anyone care about how low-level implementation
> details of IKEv2 and JFK?
If we are going to have multiple IPsec SAs between hosts, then the DPD
should be done on the upper level than IPsec SA (not to waste
resources). I.e either on Phase 1 or per host basis.
> 4.3.B) Should the working group consider other schemes which provide
> the same functionality as dead peer detection? (i.e., birth
> certificates, see section 3.5 in draft-ietf-ipsec-soi-features-01.txt)
I think birth certificates are much better than initial contact. Both
of them have problem that if the ip-address (for example because of
nat or dhcp) of the other end changes then the initial-contact or
birth-certificate is not tied to the proper host. Both of those should
propably be tied to something else than IP-address. For example they
could be tied to the ID the host is using when authenticating, i.e if
it uses IP-address then they should tied to IP-address, if it uses dns
name then it should be tied to dns-name. The ID is usefull as an
authentication id only if it somehow static, thus remains constant
even if the ip-address etc changes.
BTW, you don't need necessarely stable storage for the
birth-certificates, you can also use clock for that, and all hosts
using certificates DO need to get proper time before they can start
using the certificates (otherwise they cannot verify the validity
period).
> 4.4 SA deletion
>
> 4.4.A) Both JFK and IKEv2 provide SA deletion. The functionality
> provided is roughly identical. Does anyone care about how low-level
> implementation details of IKEv2 and JFK?
One of the issues that have raised lately has been different kind of
load balancing servers and one very usefull feature there is to be
able to pregenerate delete notification for the SAs. This way if you
have two hosts balancing the load they can both have their own SAs,
but each one sends the another node pregenerated delete (or
birth-certificate) notifications. Now if one node for some reason
crashes the other node can quickly delete all the SAs used by it and
force all clients using the other node to rekey to him.
The reason why they do not share the actual SAs is that it would
require lots of syncronization for the replay counters (in
environments where replay detection cannot be disabled for security
reasons).
If I understand correctly neither one of the protocols currently allow
this kind of pregenerated delete notifications. The IKEv1 did allow
that, but because we do not know the proper message id to be used for
the delete we cannot pregenerate the IKEv2 delete notification
beforehand.
Of course we could fix in IKEv2 this by saying that message id
0xffffffff must always be accepted and the only contents it can have
is to have delete notification for the IKE SA.
For JFK we need to share the actual authentication private key in both
nodes, to be able to send the deletes, and for each deletes we need to
do full signature + diffie-hellman...
> 4.5 SA rekeying
>
> 4.5.A) Both JFK and IKEv2 provide SA rekeying. The functionality
> provided is roughly identical, although JFK requires more
> cryptographic operations to do rekeying (see 2.4). Does anyone care
> about how low-level implementation details of IKEv2 and JFK?
See my comments earlier about not requiring the legacy system
authentication to be done for each rekey.
> 4.6 Authenticated error messages
> 4.6.A) Both JFK and IKEv2 provide authenticated error messages. The
> functionality provided is roughly identical, although details very
> different due to the lack of a 2 phase protocol in JFK. Does anyone
> care about how low-level implementation details of IKEv2 and JFK?
The problem with IKEv1 was that NO-PROPOSAL-CHOSEN error could not be
authenticated for the Phase 1, as there was not cryptographic context
when sendind that. I think this is also the case for the IKEv2.
> 4.7 Authenticated informational messages
>
> 4.7.A) Does SOI need to provide authenticated informational messages
> after an IKE SA has been set up? (What sort of informational messages
> might be needed? Do they need to be protected in a different key than
> the SA key?)
For example the SCTP might need some control message which adds new
addresses to existing SA or deletes some addresses there. I don't know
if it would be actually informational message or some other kind of
exchange (new IPsec SA creation without Diffie-Hellman?).
--
kivinen@ssh.fi Work : +358 303 9870
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/