Hi, Martin. See inline. > On Apr 27, 2015, at 2:02 PM, Martin Willi <mar...@strongswan.org> wrote: > > Yoav, > >> Oh, and one more thing: I’d really appreciate it if somebody checked my >> examples. All I can be sure of is that they work in my code. > > I've hit two issues when verifying the IKEv2 example in our code: > > > From appendix B: > >> Padding as required by RFC 7296 is 4 bytes long. > > Do we have such a padding requirement for IKEv2? For ChaCha20 we have no > requirement for input lengths, so no padding is needed. While we have 4 > byte padding in ESP, I don't think this is true for IKEv2 Encrypted > Payloads, is it? > > From RFC 7296 3.14: > >> o Padding MAY contain any value chosen by the sender, and MUST have >> a length that makes the combination of the payloads, the Padding, >> and the Pad Length to be a multiple of the encryption block size. >> This field is encrypted with the negotiated cipher. >> >> o Pad Length is the length of the Padding field. The sender SHOULD >> set the Pad Length to the minimum value that makes the combination >> of the payloads, the Padding, and the Pad Length a multiple of the >> block size, but the recipient MUST accept any length that results >> in proper alignment. This field is encrypted with the negotiated >> cipher. > > So while the used padding is not invalid, it is not what we SHOULD use, > and if so probably not a good example. Maybe we should also add a note > about IKEv2 padding to section 3?
This is actually quite unfortunate text. Fields must be aligned to block size only for CBC. Aligning AES-GCM to 16 bytes and ChaCha20-Poly1305 to 64 bytes would be totally arbitrary, yet that is what the MUST requirement in the first bullet seems to be saying. I don’t even know what “proper alignment” means for a cipher such as this. If anything is proper alignment, then the value that fulfills the SHOULD requirement is zero (with no padding bytes). For section 3, I could add a text that echoes the second bullet: The sender SHOULD include no padding and set the Pad Length field to zero. The receiver MUST accept any length of padding. Sounds good? > > > > The other issue I've seen is about the Next Payload: > >> Encrypted Payload: >> 000 00 00 00 2c 10 11 12 13 14 15 16 17 61 03 94 70 ...,........a..p > > The Next Payload field in the Encrypted Payload is 0. However, RFC 7296 > defines: > >> Next Payload - The payload type of the first embedded payload. > > So I think Next Payload should be Notify (0x29). Yes, you’re right. I’ve fixed this in my working draft. I should publish again in a day or two. Thanks. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
