Hi Bob, Am 18.11.2011 um 21:20 schrieb Robert Moskowitz:
> What is HIP_CIPHER? > > This is the cipher used to encrypt a HIP parameter (that calls for > encrypting). No HIP Parameter authentication is used, encrypted parameters > are protected with any of the various HIP_MAC parameters. > > HIP_CIPHER AES-CBC > > This is quite a reasonable cipher to use. The IV is defined variously. > However... > > 802.11 and 802.15 interfaces have AES-CCM built into them. It was pointed > out to me, that for HIP-DEX, I had added the need for the AES decrypt in > software because I was using AES_CBC for the HIP_CIPHER. So I am changing > HIP-DEX to specify AES-CTR. > > I am bringing this to everyone's attention so we can get agreement on the > construct of the counter > > AND > > Perhaps it should be added to 5201-bis as well... > > ============================================== > > No on to defining the counter. We will reference RFC 3686 for the counter > block format. We need a 32 bit nonce and a 64 bit IV and then there will be > a 32 bit block counter (quite an overkill for the size and number of > encrypted parameter blocks, but stay consistant). > > It is my proposal that R1_Counter be used for the IV and the puzzle I and J > be used for the nonce (low order 32 bits as they are larger than 32bits). Or > 'just' use I and J, their lower 96bits. > > This brings into focus that we need to specify that I and J can never be > equal (it just could happen, it can work if k=0). We use I and J as nonces > in few areas. They need to be unique. I think we missed being explicit on > this test. I and J must definitely be unique when you do static diffie Hellman. For ephemeral DH, they need to be unique if you intend to use R1 pre-creation. I think this is mentioned explicitly in RFC5201-bis but I'll check it out. For DEX with static DH it should be noted clearly in the text. There may also be a note that otherwise security is at stake because you can just wait for a IV and nonce collision with the same DH pairs to derive the cleartext messages. > > Using R1_Counter turns it from a SHOULD to a MUST if HIP_CIPHER = AES-CTR. In RFC5201-bis we already changed the Responder behavior for responding to a R1_COUNTER with a R1_COUNTER to a must. I guess it is enough to define in DEX that the Initiator MUST use a R1_COUNTER that was (pseudo)randomly selected. > > But does the update frequency of the puzzle and its potential reuse introduce > a potential weakness. The puzzle is rather cheap, and it is intended to be outside the pre-created part of the R1. The I and J Values take care that the puzzle can be made unique for each Initiator (e.g., by constructing the I value from sender HIT and sender IP addresses plus counter). However with the CTR mode, attacks against the Initiator must be considered as well. What happens when an attacker sends the Initiator a replayed R1 packet and the Initiator for some reason replies with a I2 with the same IV, same nonce, but different cleartext? The attacker could retrieve an xor of both cleartexts. For chosen cleartext attacks, this may compromise security. That's why RFC3686 says: "The same IV and key combination MUST NOT be used more than once.". Hence, the Initiator must either keep track of already used IVs or must add its own random value to the IV. Using the puzzle solution does not really seem to be good enough for the purpose here because depending on the puzzle solution implementation one may re-use solutions (or arrive at the same solution) for two identical I values and host pairs. I guess having some real (pseudo) randomness from the Initiator would make your life much easier, although it may scream for some more space for signaling this value (as you suggest below). Even this might not be enough, depending on the space for the random part of the IV. That's why RFC3686 says: "For this reason, it is inappropriate to use this mode of operation with static keys. Extraordinary measures would be needed to prevent reuse of an IV value with the static key across power cycles. To be safe, implementations MUST use fresh keys with AES-CTR." Concluding, I guess you have the choice of either tightly restricting how the puzzle must work and what exactly can be sent in the encrypted part (to avoid chosen plaintext issues) or to make the key or IV _unique_. Good keys and/or IVs sound more useful to me. > The responder would be using the same counter space in different HIP > exchanges. As long as these are with different initiators, this is not a > problem as the DH derived keys would be different. In HIP-BEX with ephemeral > DH, we are still 'safe'? But HIP-DEX with static ECDH, we could never use > the same puzzle between two HP-DEX peers. Exactly. > > An alternative would be to still use I and J for the IV, but to include a > 32bit nonce with the encrypt block that MUST be fresh with each block. > Sounds better. Is 32 bit still sufficient here if the key would be static? RFC3686 assumes fresh and unique keys which you seem not to have. > ============================================= > > Two questions: > > For HIP-DEX: how to construct the Counter Block. Good question. I tried to give some input/thoughts above. However, we should definitely have people from the crypto community onboard when doing such an adventure. I can't do much more than educated guessing when it comes to these matters. > > For HIP-BEX: is AES-CTR worth adding? I think there is no real demand at this time. If you can work it out, I would rather define it as a requirement in the BEX-DEX compatibility section in the DEX document. However, there is now a mechanism to make the ciphers exchangeable in BEX (5201-bis) so we can easily extend the existing values in the future when needed. I hope this helps. Tobias > > > _______________________________________________ > Hipsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/hipsec -- Dipl.-Inform. Tobias Heer, Ph.D. Student Chair of Communication and Distributed Systems - comsys RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://www.comsys.rwth-aachen.de/team/tobias-heer/ blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi pgp id: AEECA5BF _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
