Re: Sub/Not Security, Presence service identifiers

"Peterson, Jon" <[email protected]> writes:

> I also take it from recent list discussion that there is not a demonstrated
> need for a presence service to have an explicit identifier in a notify
> operation. Without security, such an identifier serves no purpose (it could
> be trivially forged). With the identifier, it would be redundant with the
> subjectAltName of an X.509 certificate that could be used to sign a
> notification. Regardless of whether or not such an identifier is present,
> the signature on the notification and the presentity should have some
> reference integrity, but I don't see how this identifier helps with that.

Simplicity and regularity in protocols facilitate code reuse and
correctness.  The purpose of including a 'From' header in a
notification operation is to provide a principal that identifies the
subject that initiated the operation, i.e., the name of the presence
service.  Given the principal, a client can make an access control
decision as to whether it will accept the contents of the notification
operation.  This decision can be made in the absence of a signed
request.  A client can simply choose to believe the contents in a
'From' header without a proof that it is accurate.

A client's security policy may require that any operation that claims
to be from a member of a set of trusted principals must be signed.
When this policy is in force, the client must reject any unsigned
operation that claims to be from one of the trusted principals.  As a
result, one should have greater confidence in the authenticity of
operations from trusted principals.

Notice that this security story equally applies to instant messages.
The only difference is that the 'From' header of a message contains a
principal that identifies a person instead of a service.  The software
that handles instant messaging authentication can be applied unchanged
to notification authentication.

Think about it this way.  When a presence service generates a signed
notification operation, part of the signed content must include a
timestamp, otherwise, the protocol will be vulnerable to replay
attacks.  The instant message format includes a 'DateTime' header
which is included in the signed content, and thereby protects it
against replay attacks.  Is anyone on this list seriously proposing to
not use instant messaging's timestamp syntax for notification
operations?  I don't think so.  When this group gets around to
defining a subscription operation format that can be signed, I am
confident it will also use instant messaging's timestamp syntax.  In
that case, the software that handles instant messaging timestamp
processing can be applied unchanged to every presence operation.  We
should strive to ensure that the software that handles instant
messaging authentication can be applied unchanged to every presence
operation too.

There are proven practical reasons for preferring simple, regular
protocols.  I have direct experience in this area.  The SIMP protocol
embodies these design principles.  I wrote the SIMP server and the
security module used in all SIMP clients.  The code review of the
security elements was quick because the high-level security story was
easily conveyed, and the amount of code was small.

I think the people that specified the format used for instant
messaging did a fine job.  Their design was so good that I think the
presence protocol should reuse their ideas wherever possible.  People
promoting an irregular protocol should explain why they believe ideas
from the instant messaging format are not worthy of reuse.

John

  There are two ways of constructing a software design.
  One way is to make it so simple that there are obviously
  no deficiencies.  And the other way is to make it so
  complicated that there are no obvious deficiencies.
                                          --- C.A.R. Hoare



  [reminder: [email protected] for non-technical discussions, please]