[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: photuris-06.txt
Thanks, Ran. 4K message; rather a lot. Well, here goes....
> From: Ran Atkinson <rja@bodhi.cs.nrl.navy.mil>
> 1.6: Please replace the string "in Multi-Level Secure
> environments,"
> with the string "for multi-user systems,"
>
Not intended for plain-old multi-user systems. Too many holes. Cannot
guarantee correct operation of the protocol. Folks have already
indicated some of the holes on this list.
Also, if there are no "levels" of security (that is, all users are
authorized to the same access control or the access control is not
mandatory), then there is no reason for separate user-level keying.
They can read each others' traffic.
For plain-old multi-user operating systems, node-node keying is the only
technique available. This secures IP from _outside_ interference, even
when the end-systems themselves are not secure.
> 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.
>
That's certainly the expected current case.
> 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.
>
It _IS_ a MUST to _try_ Photuris (how would it know _not_ to try?), just
not a must succeed. But then, nothing is. And trying is better than
nothing. So, that is when an exchange begins. Always.
As described last week in the scenarios, if another admin prohibited is
received for Photuris, _then_ quit.
> 2.4: Delete the sentences below because the document should only
> specify mechanism and must not specify policy.
> ...
> "Encryption policy is in the SPI User (sender) direction."
>
> "Authentication policy is in the SPI Owner (receiver) direction."
>
Your assertion is correct. Your analysis of the division is not.
Note that the policy itself (Joe can only use FTP not Telnet) is not
specified. Only the direction of the policy, as required by the
mechanism.
Your other comments are already discussed:
Each party implements local policy that determines what access, if
any, is granted to the holder of a particular identity. For |
example, the party might allow anonymous FTP, but prohibit Telnet. |
Such policy considerations are outside the scope of this document.
> 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."
>
Good ideas. How about:
When choices are made from the set of Offered-Attributes, it is not
required that any Security Association include every kind of offered
attribute in any one SPI, or that a separate SPI be created for
every offered attribute. These combinations are implementation
dependent.
> 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."
>
That seems awkward to me, as that phrase was used in the previous
sentence. How about:
The Responder secret random value MAY remain the same for many
different Initiators. Instead, this secret SHOULD be changed
whenever the Responder Exchange-Value is changed.
> 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.
>
(Sigh) and I changed it to this a couple of rounds ago at another
suggestion. Sure, why not.... (both places)
Reserved one octet. For future use; MUST be set to zero when
transmitted, and MUST be ignored when received.
> 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.
>
It's in the ME and EC sections you asked to be moved to the end (which
used to be at the beginning).
It already has an explicit reference to the "Scheme Choice", which in
turn references the "Exchange Scheme Appendix", which in turn (for each
scheme) references ME or EC.
That's pretty thorough!
> 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."
>
Sorry, but that's MD5, DES-CBC-32, and DES-CBC-64. They are indicated
in the Appendix. It already says all that:
The formats are specified in the "Attribute List"
Appendix, where mandatory attributes are also
specified. The end of the list is indicated by the
> 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.
>
Same response.
> 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.
>
This is already official IANA-speak. "unassigned" is the term for
something which IANA can assign. "reserved" means IANA cannot assign it.
However, I could add some verbiage that unassigned numbers must be
requested from IANA:
Up-to-date values for the Attribute Type are specified in the most
recent "Assigned Numbers" [RFC-1700]. Implementors wishing a number
indicated as "unassigned" MUST request the number from IANA. Initial
values are assigned as follows:
Bill.Simpson@um.cc.umich.edu
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Follow-Ups: