Re: light comment on security provisions.

[Sheer El-Showk <sheer@saraf.com>]

Hi,

I think the design teams are intended to be long-term overseers of their
particular areas as we develope the protocol.  You're suggesting that the
requirements has already address the needs for certain kinds of security
and you're probably right (which is why we're trying to finalize the
requirements document).  The task of the security design team is now going
to be to address these issues and help descide at what level (protocol or
transport) these issues are going to be addressed.

As to your other point (regarding security being a local consideration),
there are some necassary clarifications here.  While data-access might be
a local consideration, data protection for the most part will not be (with
the caveats of maximum encryption strength and governement tap-in
laws).  Eric proposed considering P3P to publish local data access
preferences and I think this is an important part of the protocol.  The
subtle point here is that while data access laws might vary and different
methods might be employed to ensure security, where-ever this may vary
different entities have to have a way of publishing this so others
communicating with them can understand what restrictions are in place (eg
can't query by contact).  Some meta-protocol concept like this is also
relevant for describing what subset of provreg a site supports (this is an
unrelated concern but something that might want to be brought up in the
protocol design team).  These issues have been hashed out in the past but
I don't remember any closure anywhere and they're being brought up again
so I've mentioned them here.

Regards,
Sheer

On Wed, 21 Mar 2001, Bruce Campbell wrote:

> 
> This is in the 'am I missing something here' vein, however the drafts
> already released (as listed in the IETF WG charter page) have wording
> which covers in-transit security, which seems to be most of the security
> concerns being brought to the microphone, ie:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-00.txt
> 
>  11. Security Considerations
> 
>   [1] Security services MUST be provided to protect against the
>   following types of attack: eavesdropping, replay, message insertion,
>   deletion, modification, and man-in-the-middle.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-00.txt
> 
>  7. Security Considerations
> 
>   EPP provides only simple client authentication services.  A passive
>   attack is sufficient to recover client identifiers and passwords,
>   allowing trivial command forgery.  Protection against most common
>   attacks must be provided by other protocols.
> 
> The actual security provided is (as someone, Bill?) pointed out, dependent
> on country laws which one or both of the Registrars/Registries must
> observe, and as such, could be left as an issue between the individual
> Registrars/Registries. (ie, whatever the local laws/customers allow/want).
> 
> --==--
> Bruce.
>