SOI QUESTIONS: 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 3.1, 3.2.

[Tero Kivinen <kivinen@ssh.fi>]

> 2.1.A.)  Does SOI need to provide protection against passive
> attacks for the initiator?

Yes. 

> 2.1.B.)  Does SOI need to provide protection against active
> attacks for the initiator?

No.

> 2.1.C.)  Does SOI need to provide protection against passive
> attacks for the responder?

Yes.

> 2.1.D.)  Does SOI need to provide protection against active
> attacks for the responder?

Yes, because of the identity sniffing attack.

> 2.2.A) JFK and IKEv2 can provide PFS as well as "imperfect forward
> secrecy" by trading off performance versus the level of PFS provided.
> The funcitonality provided is roughly identical.  Does anyone care
> about the details of how IKEv2 versus JFK provides this functionality?

Yes, PFS is important, details are not that important. 

> 2.3.A.)  Does SOI need to natively support "legacy authentication
> systems"?

I think, that we do need to do something for the legacy
authentication. I really want to get rid of xauth, and if we don't
have some solution, I fear that we will see the xauthv2...

So, some kind of solution should be in the SOI. I think something like
rsa signatures authentication for the server/gateway and legacy
authentication for client/remote user.

> 2.3.B.)  Does SOI need to natively support some kind of "shared
> secret" scheme?

No. It could be usefull for the debugging and very small scale
testing, but same can be archived with raw RSA keys (or self signed
certificates). For the legacy authentication I think we need strong
RSA signatures based authentication for the gateway/server, thus this
is not useable for it.

> 2.4 Number of crypto operations
> 
> 2.4.A) JFK requires substantially more cryptographic operations for
> rekeying (two more signatures, two more signature validations, and
> three more hashes).  Is this a problem?  More generally, does SOI need
> to be able to support "fast" rekeying?

I think number of crypto operation is very important for small
devices, and they will be more and more common. The fewer operations
we have the smaller devices we can use...

Fast rekeying is important on some scenarios, for example it could
have uses for cases where we move lots of data (iSCSI?). Also if
rekeying requires new authentication that means that for legacy
authentication support we need user to do something to perform the
authentication.

> 2.5)  Plausible denaibility 
> 
> 2.5.A) Does SOI need to provide "plausible deniability" (the opposite
> of "non-repudiation") for the initiator?

No.

> 2.5.B) Does SOI need to provide "plausible deniability" (the opposite
> of "non-repudiation") for the responder?

No.

> 2.6 Formal proofs of security
> 
> 2.6.)  Does SOI need to provide a formal proof of security?  (Is this
> a "must have" or a "nice to have"?  What are we willing to trade-off
> for having a formal proof of security?)

Formal analysis are nice to have, so we can say to customers that yes
this is "secure" protocol. I don't really think trust those very much.
Also most of the security problems are going to be in the
implementations anyways so for me as an implementator it really
doesn't help to have formal proof...

> 3.1.A) WRT DOS attacks that exhaust memory or CPU resources, is it more 
> important to always keep the message count at 4, or is it acceptable to add 
> an additional roundtrip of messages when the responder thinks he's under 
> attack?

I think it is acceptable to add more roundtrips when responder thinks
he is under attack. 

> 3.1.B) WRT UDP fragmentation attack protection, both IKEv2 and JFK provide 
> basically equivalent protection. Does anyone care about the details of how 
> JFK or IKEv2 provide this functionality.

I think the best approach is to try to keep the packets small, but
otherwise it really does not matter.

> 3.1.C) Is it important to have precomputation of exponentials available for 
> use as a mechanism for protecting against cpu consumption attacks?

For some scenarios yes, but I actually think this is more or less
implementation issue (our IKEv1 implementation can precompute
Diffie-Hellman exponentations even now).

> 3.2 Number of messages in all scenarios
>
> 3.2.A)In both IKEv2 and JFK, Alice chooses a Diffie-Hellman group in 
> message one. In IKEv2 if Bob doesn't accept what Alice offers the 
> negotiation starts again. In JFK if Bob doesn't accept what Alice offers 
> but Alice can live with what Bob offers, they continue. Otherwise they 
> start over. Is this an important feature for SOI?

I don't think that is going to be that common case that we need to
optimize for it. I think it is fine to just send back a error
notification listing allowed groups. Implementations should try to
remember those lists, and try those groups next time first.
-- 
kivinen@ssh.fi                               Work : +358 303 9870
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/