[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposed changes to ISAKMP/Oakley
Daniel Harkins writes:
> > 1) The oakley draft specifies the format of variable lenght
> > integers, but that format is NOT used by isakmp/oakley. The
> > isakmp/oakley draft should say how variable length integers
> > are send in KE payloads (length in payload length, data
> > directly in payload, no extra padding), and how they should
> > be added to HASH (are leading zeros allowed in g^x)
> The base ISAKMP draft defines this. There would be no padding added unless
> this was the last payload in a Quick Mode exchange and it was necessary
> for encryption.
I was not talking about payload paddings, I was talking about padding
the variable length integer in the payload and encoding of it in the
payload. The isakmp draft just says the key exchange payload contains
the key exchange data that is specified by the doi and the associated
key exchange algorithm.
The oakley draft says:
] In the following we indicate where each OAKLEY field appears in the
] ISAKMP message structure. These are recommended only; the Resolution
] document will be the final authority on this mapping.
] CKY-I ISAKMP header
] CKY-R ISAKMP header
] MSGTYPE Message Type in ISAKMP header
] GRP SA payload, Proposal section
] g^x (or g^y) Key Exchange Payload, encoded as a variable precision integer
...
and then it defines encoding for variable precision integers as
following:
]APPENDIX C Encoding a variable precision integer.
]
]
] Variable precision integers will be encoded as a 32-bit length field
] followed by one or more 32-bit quantities containing the
] representation of the integer, aligned with the most significant bit
] in the first 32-bit item.
]
] 1 2 3
] 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
] ! length !
] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
] ! first value word (most significant bits) !
] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
] ! !
] ~ additional value words ~
] ! !
] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]
] An example of such an encoding is given below, for a number with 51
] bits of significance. The length field indicates that 2 32-bit
] quantities follow. The most significant non-zero bit of the number
] is in bit 13 of the first 32-bit quantity, the low order bits are in
] the second 32-bit quantity.
]
] 1 2 3
] 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
] ! 1 0!
] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
] !0 0 0 0 0 0 0 0 0 0 0 0 0 1 x x x x x x x x x x x x x x x x x x!
] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
] !x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x!
] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note, that the length field have the number of 32 bit words and the
integer itself is always prefixed with zeros so its length will be
will be multiple of 32 bits.
So when I read those drafts I assumed that this encoding was used,
because the isakmp-oakley draft or doi didn't say anything to modify
this.
Also if we interpret the value in KE payload as variable precision
integer it value remains same even if we add the zeros in front of it.
This means the Diffie-Hellman might succeed (if we don't check the
length in bytes, but check that value is smaller than p), but then we
have to use the form transmitted on wire (with leading bytes of zeros)
in hash, not the variable precision integer used in Diffie-Hellman
calculations.
BTW, if I understand isakmp-08 correctly it says the complete message
(but not the payloads inside the message) MUST be padded to 4 byte
boundary (that is before encryption padding is added):
] 3 ISAKMP Payloads
...
] changes (see Section 4) are shown using network octet ordering. Addition-
] ally, all ISAKMP messages MUST be aligned at 4-octet multiples.
> Let me know how that sounds. Suggested text is greatly appreciated if this
> is not adequate.
Sounds good.
> > 4) Draft should state clearly that there is only one cipher
> > context/IV shared in both directions. At least I
> > automatically assumed there is one cipher context/IV
> > for encryption and one for decryption (ie separate contexts
> > for each direction).
> Can you tell me where you think this should go? Along with the description
> of IV generation for phase 1 (in Appendix B)?
Yes, just adding something at end of this paragraph in appendix B:
...
] pad since this reflects the size of the cyphertext. Subsequent
] messages MUST use the last CBC encryption block from the previous
] message as their initialization vector.
--
kivinen@iki.fi Work : +358-9-4354 3205
Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-9-502 1573
References: