Hi Dan,
My apologies if this is coming a bit of late.
I have a few comments in-lined below for the Security Considerations
section.
>7. Security Considerations
>
> Intermediaries open up a large number of new security problems which
> do not exist in the classical end-to-end model of the Internet, by
> introducing a 'Man In The Middle' by design.
>
> As such, it is essential that this protocol level work on
> intermediaries takes care to devise means by which the integrity of
> the resources being updated can be preserved - or at least tested.
>
> Following are the security thread models:
>
> 1. Authentication and authorization: the protocl should be able to
> authenticate the parties of a session before commencing the
> session, so that no un-authorized parties may participate the
> session.
I'd suggest Authentication and Authorization be in separated bullets,
as they are independent issues in security. (Authenticating parties
prior to a session actually means authorization, which may take the
form of ACL, user/password, certificates (e.g. client authentication
in SSL/TLS), kerberose, etc. It's about gatekeeping. Authentication
entails knowing messages by an RUP client indeed came from the right
RUP server(s), and in the right sequence -- a drill of vigilance.)
> 2. Session integrity: the protocol should be able to ensure the
^^^^^^^^^^^^^^^^^
> integrity of the resource uupdate messages, so that any
tempering
> can be detected and/or recovered from.
"Message integrity" perhaps?
An attacker may trash a session, but not necessarily the messages
communicated, thus the end-points may still salvage some values out
of a damaged session. E.g. the invalidation signals received up
to the time a session was compromised are still deemed good by a
RUP client.
BTW, if the bullets are listed as:
1) Authorzation: the protocol MUST be able to allow a server to
limit the access to a session to authorized paries only.
2) Authentication: the protocol MUST be able to authenticate the
messages among session participants.
3) Session/Message Integrity: ...
then a MAC (Message Authentication Code) capability like HMAC can
easily satisfy both 2 and 3.
Note that I tend to use MUST's instead of should's in current context,
because security is a non-comprising matter. You do it; or you don't.
(Half-hearted or half-baked security is as good as no security.)
> 3. Sessio secrecy: the protocol should be able to ensure the
secrecy
[Nit] ^^^^^^ Typo, missing n.
> of the resource update messages, so that no un-authorized
parties
> can eavesdrop the session.
>
> 4. Denial of service: the protocl should provide counter measures
to
> denial-of-service attacks, such as distributed SYN flood or
> resource update storm.
This is IMHO too much to ask of RUP, which sits well above the transport
layer. E.g. how is RUP to counter bogus TCP RSTs from attackers?
So, RUP may as well rule DOS issues out of scope.
> 5. In-band security: the protocol should be able to prevent trusted
> parties from flooding and/or disabling the RUP service,
> accidentally or intentionally.
This lies outside the conventional security models, which deal with:
authorization, authentication, (message) integrity, and confidentiality.
In practice this is extremely difficult to do, (i.e. prohibitively
expensive,) guarding against enemies from within who are also occasional
friends. I'd move this out of this section, or out of the doc entirely.
Joe Hui
Digital Island, a Cable & Wireless company
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:23:00 MST