[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

photuris-06.txt

Personal comments on the photuris-06.txt draft, mostly organised
by document section...

1.6:	Please replace the string 	"in Multi-Level Secure
environments,"
	with the string			"for multi-user systems,"

2.0 (2):   It is conceivable that not all ICMP Dest Unreachable,
	Communication Administratively Prohibited messages that are
	received will relate to IPsec.  It is possible that they might
	originate at a Firewall that does not implement IPsec, for
	example.

	   Hence, I'd like to suggest that this text be clarified so
	that an implementation understands that receipt of such an ICMP
	message might be good cause to try Photuris but that it is not
	a "MUST" requirement to try Photuris in that case.

2.4:	   Delete the sentences below because the document should only
	specify mechanism and must not specify policy.  Different sites
	can and will have different policies.  Policies are not
appropriate
	matter for a regular standards-track document.  I  don't yet
	fully understand the new BCP document class, but it is
conceivable
	that one might specify a policy in a BCP style document that is
	separate from the mechanism document.

	...
	"Encryption policy is in the SPI User (sender) direction."
	...
	"Authentication policy is in the SPI Owner (receiver) direction."
	...


	   I don't understand the meaning of the sentence below.  Please
	either clarify it or delete it.  Perhaps you are trying to say
	that "choices are made from the set of offered attributes and
that
	a node does not need to create an SA for each possible
combination
	of offered attributes" ??

		"It is not required that a Security Association be
created
		including every offered attribute, or that a SPI be
created
		for every offered attribute."

3.3:	  I propose rephrasing
		"Instead, the secret SHOULD be changed at the same
		frequency as its Exchange-value."
	  to instead read
		"The Responder secret random value SHOULD be changed at
		the same frequency as its Exchange-value."

4:	Instead of saying "unused", I'd suggest saying "Reserved for
	possible future use" so that folks clearly understand that
	this is not a field that they can play with.  This comment
	repeats throughout the remainder of the draft.

4.1:	How does the Initiator determine the Initiator-Exchange-Value ?
	If this is explained elsewhere in the Photuris spec and I
	missed the explanation, then that means an explicit section
	reference is needed here.

	Which 3 Security Parameter attributes are required ?
	I wonder if this might be trying to say something like:
		"The Initiator-Offered-Attributes MUST include
		at least MD5, DES-CBC, and some certificate."


4.2:    Same comment as for 4.1 about "3 minimum Security Parameter
	attributes". I HAVE read the spec but it is not really clear
	which 3 are mandatory.


B:	Please change "unassigned" to read "Reserved to IANA" for the
	Attribute Type numbers.  It is important that people understand
	that they cannot just take and use these numbers wantonly.

I didn't finish all of the material after 4.2 in draft-06, but think
it is probably sensible to go start on draft-07a (though you won't
get comments from me until Monday at the earliest).

Ran
rja@cs.nrl.navy.mil