[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Changes in version 8 resulting from comments in: Re: questions about draft-ietf-shim6-proto-06.txt
These are the changes that i have made in the version 8 of the proto
document based on these comments:
El 05/12/2006, a las 14:54, Matthijs Mekking escribió:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
My name is Matthijs, and I am doing research on shim6 for Radboud
University Nijmegen/NLnetLabs Amsterdam (Netherlands). I have a couple
of questions about draft-ietf-shim6-proto-06.txt that seem a bit
unclear
to me. Some of them are maybe obvious comments, but I shall make them,
because I think it is good for a protocol description to allow only one
clear interpretation.
1. Wat is exactly meant with VALIDATOR_MIN_LIFETIME? According to the
draft, "the peer might reject Responder Validator options that are
older
than VALIDATOR_MIN_LIFETIME to avoid replay attacks" and "Nonces that
are no older than VALIDATOR_MIN_LIFETIME SHOULD be considered recent".
Does this value apply to both nonces and responder validator options?
Is this value solely used by a host acting as responder?
If so, do you agree that this value should be used outside SHIM6?
Because a responder may not store state (yet) and thus can not verify
if
a nonce in an I2 or I2bis message may be considered recent. If you
agree, can't this value be omitted from the document (since it is
independent of the correct working of SHIM6, but merely a security
consideration of the host)?
The version 7 of the document seemed unclear of how the Responder Nonce
lifetime was determined since no per context state was sotred. I have
updated the draft, to make clear that the Responder nonce is obtained
from a counter that is increased in fixed periods (indepedently of any
shim6 proto event) which allows to determine the age of a Responder
Nonce just by comparing it with the current value of the counter.
....
5. In chapter 6, a conceptual model of the host is given. However, the
second table in section 6.2 introduces some new elements that are not
described in section 6.1: INIT nonce, RESP nonce and CT(R1bis). I
suggest that they (including a short description) are added to section
6.1.
I have added Init nonce, Responder nonce and responder validator as
additional information available in the conceptual model during the
establishment phase
6. Am I right that the RESP nonce in I2-SENT is stored so that the host
is able to create the correct I2 retransmission? If so, than the
responder validator should also be stored (because this is also copied
from the R1 message, just like RESP nonce).
added responder validator as information available in I2-SENT state
If this is the reason, than
I think RESP nonce, INIT nonce and the responder validator should also
be stored in state I2BIS-SENT.
Added RESP nonce Init nonce and Responder validator in I2BIS-SENT
7. In the text, computing a responder validator looks inconsistent with
generating the validator:
For R1 the secret S, the Initiator Context Tag and the locators are
omitted when computing the validator:
"use the following information concatenated as input to the one-way
function:
o The the secret S
o That Responder Nonce
o The Initiator Context Tag from the I1 message
o The ULIDs from the I1 message
o The locators from the I1 message (strictly only needed if they are
different from the ULIDs)
o The forked instance identifier if such option was included in the
I1 message"
(section 7.10.1, page 62)
and
"that the Responder Validator option matches the validator the host
would have computed for the ULID, locators, responder nonce, and FII."
(section 7.13, page 63).
added the init nonce in the description here
For R1bis the secret S and Receiver Context tag are omitted when
computing the validator, but the ULID and FII are added:
"use the following information concatenated as input to the one-way
function:
o The the secret S
o That Responder Nonce
o The Receiver Context tag included in the received packet
o The locators from the received packet"
(section 7.17.1, page 68)
and
"the Responder Validator option matches the validator the host would
have computed for the ULID, locators, responder nonce, and FII as part
of sending an R1bis message."
(section 7.20, page 69)
removed the ULID and FII from the description above
added the receiver context tag
Thanks again for this review, hope you find these changes ok
Let me know of further comments
Regards, marcelo
With kind regards,
Matthijs Mekking
matthijs@NLnetLabs.nl
NLnetLabs/Radboud University
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFdXocNiaStnTWEtYRAo3nAKC+sB2E/8YxJQ6PR7AzORZ6gEKyOgCeJccj
UQAPF0SpqzlfSZT7smcf++k=
=P4tt
-----END PGP SIGNATURE-----