Subject: [Sip] comments on draft-peterson-message-identity

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 06 Mar 2005 09:12:17 -0500

Sorry I've only finally gotten around to giving this a detailed read. 
I'm sending these comments to the sip list because the draft is up for 
discussion there.

Firstly, this is an excellent, excellent document. A thorough treatment 
of the design issues involved in identity assertions in messaging 
systems. I really hope it moves forward to RFC, though I think its 
probably outside of the scope of the sip related groups.

Some high level comments. I was disappointed that there wasn't a more 
thorough discussion on verification assertions. Its mentioned in passing 
in appendix B, but I think its likely to be an essential part of the 
story. Indeed, it interacts substantially with the online/offline 
arguments around keys by reference or by value. If an "always online" 
server like a mail server does the verification, and passes the 
verification assertion by-value, the identity assertions can be by 
reference, and offline messaging can still be provided. As such, I think 
this topic really needs to be expanded and many of the issues discussed:

   a. what kind of information is passed to the end user
   b. what is the behavior if the identity assertion fails - does the 
message get passed with some kind of indication of failure, or is it 
discarded?
   c. how is the verification assertion secured?

Another topic not treated is who inserts the identity assertion. If its 
a domain assertion, does the domain insert it, or is the assertion 
passed to the originator? This reflects the design choices between older 
versions of the sip-identity draft and the new one.

Section 8 - reference integrity. There is a general principle here that 
I think is missing. The reference indicators should be selected to 
include information that would need to be modified by an impersonator 
desiring to replay the message, in order for that attack to be useful. 
If a field is something that an impersonator would be happy to leave 
alone, as they could accomplish their attack without changing it, it is 
useless as a reference indicator.

8.1: the information that is conveyed in the message for indicating the 
dynamic reference indicators, must itself be a reference indicator for 
security purposes

For replication - there isn't unlimited flexibility on what part of the 
message content can form the reference indicators. It has to include a 
minimum set of information, else the identity assertion becomes weakened.

Section 8.2: usage of date as a reference indicator - this requires 
rougly syncrhonized time between sender and receiver. Can sometimes be a 
problem. Also gets complicated unless the sending dates are expressed in 
UTC. If they are expressed in other timezones, then conversions are 
needed and this can get really complicated.

Section 8.3: when you are talking about keys by reference or by value, 
you mention the possible need for the message originator to obtain keys. 
I was uncertain of why it would need to do this - is this for storage of 
private keys ala sacred? I think you mean only for the purposes of 
including keys by reference on behalf of the domain provider. Should 
spell this out up front in the paragraph where it is discussed.

Section 10: there is another solution here for anonymization, which is 
that the anonymization service is provided by my normal provider, but is 
done using a large number of domains they have registered. The 
relationship of these domains to my provider would not be discernable 
form the domain names, and furthermore, the provider could ensure that 
other data sources could not be used to correlate the domain name with 
the service provider.

>  Another important form of privacy relates to preventing
>    intermediaries responsible for message transfer from reading the
>    identity assertion.  Encryption of assertions entails a very
>    different key distribution problem than identity.  In order to send
>    an encrypted message to a recipient, the recipient must possess a
>    corresponding decryption key.  This key needs to be shared, in some
>    fashion, with the identity provider before the identity provider can
>    encrypt the assertion for that recipient.  The problem is complicated

you need to be clear here on terms. When you say "intermediary" in the 
beginning, you mean intermediaries BESIDES the identity provider. The 
identity provider is also an intermediary between the originator and 
recipient.

> Accordingly, an assertion must cover more than just the originator's
>    name.  It must cover enough additional information that the assertion
>    cannot be replayed in a substantially message.

substantially similar

Appendix C: colons need to be placed after each hangText value; it is 
hard to separate it from the text that follows.

Your definition of third party assertions in appendix D rules out a 
common case; third party call control in SIP. In that case, the sender 
of the message may be the domain of the user, but the message is 
originated by a device or agent acting on behalf of the user, not the 
user themselves. Though, perhaps this distinction is meaningless....

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip