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

Re: editorial on Photuris

> From: atkinson@itd.nrl.navy.mil (Ran Atkinson)
> [My co-chair hat is on]
>
And therefore I will be particularly explicit:


> % I have no idea what you are talking about.  PGP is not supported in the
> % base spec.
>
> Then add it now.  See recent note from Phil Karn to the IPsec
> list agreeing this was OK.
>
No.  Phil said no such thing.  He very carefully qualified his comment
with "if that's all there is to it".  In fact, it's much more complicated.

Only certificate techniques required to be supported by all
implementations forever are included in the base spec.  There is no WG
agreement on a particular form of RSA certificate.  See recent (and many
months of previous) messages.

Only a simple MD5 "MAC" is required for initial deployment of Photuris.

PGP, PKCS, DNS-SIG and X.509 are not required for correct operation of
Photuris.


> % It has been thusly revised:
>
> Either you really don't seem to be willing to cooperate OR you really
> don't follow the discussions so far, so I am reluctantly providing
> VERY specific guidance on the text.  Please go edit accordingly.
>
I have very carefully followed and participated in the discussion.


> %    Internet Security protects against threats that come from the
> %    external network, not from mutually hostile users of the nodes
> %    themselves. Any secure multi-user operating system MUST be able to
> %    protect its resources from hostile users, and protect one hostile
> %    user from damaging the resources controlled by another hostile user.
>
> Delete above paragraph.
>
No.  This is fundamental to IP Security itself, and this text has been
agreed upon by the authors of Photuris.


> %    When required for secure multi-user environments with discretionary
> %    access controls, the Photuris Identification can be used to provide
> %    separate limited authentication from each user of one node when
> %    communicating with another common node. To provide user-oriented
> %    keying, the nodes can initiate multiple concurrent Photuris
> %    exchanges. These may provide separate user Identification from the
> %    Initiator to the Responder in each direction.
>
> Rephrase "secure multi-user environments" to "multi-user environments"
> in the above.
>
No.  Insecure multi-user environments are not within the scope.


> %    Each secure multi-user operating system MUST be capable of
> %    separately maintaining multiple Identification Exchange SPI values
> %    for each Value Exchange calculated shared-secret. It is the
> %    responsibility of the Source to internally segregate the
> %    shared-secret and different session-keys provided per Destination,
> %    and select an appropriate SPI for each datagram transmission.
>
> Rephrase "secure multi-user operating system" to "multi-user operating
> system" (or if you prefer "multi-user operating systems having
> discretionary access controls") in the above.
>
No.  Insecure multi-user environments are not within the scope.


> % And in the implementation notes:
>
> %    Successful use of user-oriented keying requires a significant level
> %    of operating system support. If the operating system has a security
> %    vulnerability, then there is no basis for separate user-oriented
> %    keying.
>
> Delete the word "significant".  We built it in BSD already and it is
> _NOT_ that hard to do, sorry.
>
No.  While I am glad to hear that all BSD applications suddenly support
user-oriented keying without any significant change in API, I look
forward to your demonstration of such at Dallas, including source.


> %    Use of multi-user segregated exchanges likely requires added
> %    functionality in the transport API of the implementation operating
> %    system. Such a mechanism is outside the scope of this document.
>
> Replace "likely" with "might" in the above.
>
Huh?  Bad sentence, does not parse.


> %    It has been suggested that the Photuris exchange could also be
> %    established between particular application or transport processes
> %    associated with a user of a node. Such a mechanism is emphatically
> %    outside the scope of this document.
>
> Delete above paragraph.
>
No.

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: