RE: Sub/Not Security, Presence service identifiers

I really really must make time to read through the latest drafts to
ensure that I am up-to-date, but in the interests of discussion, I want
to ask the following question - if this is covered somewhere, please
excuse me and point me to the appropriate text.

My understanding of the requirements was that we are aiming for
end-to-end security. Wouldn't this mean that I would expect to receive a
presence document signed by the principal rather than one signed by some
arbitrary presence service address?

Adrian.


On 19 August 2002 11:27, John D. Ramsdell wrote:
> "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]
> 
>