NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 13-Oct-00
Harald Alvestrand <firstname.lastname@example.org>
Leslie Daigle <email@example.com>
Applications Area Director(s):
Ned Freed <firstname.lastname@example.org>
Patrik Faltstrom <email@example.com>
Applications Area Advisor:
Patrik Faltstrom <firstname.lastname@example.org>
To Subscribe: email@example.com
Description of Working Group:
This working group will eventually define protocols and data formats necessary to build an internet-scale end-user presence awareness, notification and instant messaging system. Its initial task is to determine specific design goals and requirements for such a service. The design goals document will be submitted for IETF-wide review, and based on that review, the group's charter will be extended.
Instant messaging differs from email primarily in that its primary focus is immediate end-user delivery. Presence information was readily accessible on internet-connected systems years ago; when a user had an open session to a well-known multi-user system, his friends and colleagues could easily tell where he was connected from and whether he was using his computer. Since that time, computing infrastructure has become increasingly distributed and a given user may be consistently available," but has no standard way to make this information known to her peers. This working group will design a system to address this need.
The working group will develop an architecture for simple instant messaging and presence awareness/notification. It will specify how authentication, message integrity, encryption and access control are integrated. It is desirable, but not required, for the working group to develop a solution that works well for awareness of and communication with entities other than human users.
Providing a general notification mechanism for data other than user presence information and instant messages.
The following keywords describe the scope for the working group. Details are to be developed in the architecture document which is the output of this working group:
- INSTANT MESSAGING
- ACCESS CONTROL
The working group plans to deliver the following document:
- Requirements for Instant Messaging and Presence
Goals and Milestones:
Submit Internet-Draft of Design Goals for Instant Messaging and Presence Information
Submit design goals Internet-Draft to IESG for publication as an RFC
Request For Comments:
A Model for Presence and Instant Messaging
Instant Messaging / Presence Protocol Requirements
Instant Message and Presence Protocol working group
Fri Dec 15, 2000, San Diego
Chairs: Harald Alvestrand and Leslie Daigle
Notes taken by Larry Masinter
* Stage setting: Harald
Lots of discussions during the week; possible to make progress? Only required element of agenda: go home at the end.
How many people read the drafts? Most had not.
Overview: CPIM was intended to address common elements.
Harald showed a diagram:
[client1] ---user purpose ----> [client2]
| [server1] -------------------> [server2] |
When you introduce multiprotocol messaging, things get complicated. IMXP could be used between client 1 & server 1, and between server 1 and server 2. Server 2 could use SIP protocol with Client 2.
Security: 3 steps, if someone is out to get you, you need security: if any of the links can be attacked, the "bad guy" could intercept, for example, [server1] to [server2] and intercept traffic.
Q: Are attacks easier in multiprotocol than in simple protocol? A: No
Authenticating messages with digital signatures requires that messages don't change end-to-end. That means that the message format needs to be common end-to-end....
This led to a presentation by Derek Atkins, who gave an overview of the outcome of several offline discussions through the week between some of the active participants in the various proposals on the table. This covered a common message format for IMPP. Derek notes that "multi-protocol" makes security harder because it is necessary to trust the gateway, as well as the problem that if the gateways change the data format, signatures won't work.
First goal: get 3 camps to agree.
- common format would be good
- agree on a core format:
All three camps must include MIME support already
Only IMXP uses XML
- Lowest Common Denominator
- Message Format should be MIME-based
Q from the audience: We can't assume AOL will adopt a common format... A: then they won't benefit from security and can do message translations at their gateway as well as security translation.
What does this mean?
Recommend new MIME-type:
Standard format for message/cpim
- Message Metadata (headers)
- Content Metadata (MIME headers)
- Message content
* CPIM messages are immutable enroute
- Cannot re-order, remove, add, or change headers
- Cannot re-code the message (transfer encoding, line endings, etc.)
* CPIM messages may be re-wrapped
- Use security multiparts for Signatures or Encryption
* More on message headers
Use RFC822-style key:value format, without the gunk
Encode in UTF-8
One-line, one-header (no multiline headers)
(This really is a binary format, not a text format)
Define a set of common headers:
- Required headers (all messages must contain, e.g., From, To)
- Optional headers (all processors must understand)
- Pre-defined headers (defined, not required)
- Header extension mechanism
Q: defining anything about EOL sequence?
Requirements on Transport Protocols:
NOT required to use canonical format, but are required to recreate the canonical format for any message
(if transport uses its own message format, must maintain enough info in order to exactly rebuild the canonical format at the receiver)
Q: If "Reordering is not allowed", what is the mechanism for detecting mutation?
A: Signatures are necessary to tell that the message has been changed.
Q: Comment: trying to do 822 on palm device, was trying to low memory footprint. Consider restricting multipart/alternative, or add header to deal with it. Maybe the data header should just be a number, to avoid people trying to stick funny date formats.
Why use CTE? Won't.
Dave: to help people with comments, what kinds are comments are important now? Proposing an approach to the problem, but details don't have to be locked down as part of the philosophical approach.
Comment: "like HTTP and RFC 822" rather than "like RFC 822".
Comment: consider using HTTP header extension
If you don't go for this method, and you go for a gateway, you have forced a level of trust into the model, where both sides trust a common third party. Most intermediaries would not show you their trust model.
Don Eastlake: want to be able to add insecure information to header of message. Transport might include a set of transport headers that might even duplicate information that's part of this.
Q: Given that the message can be reformatted during its route at the end it is changed back to the the format where you can verify the signature. A: Lossless compression is acceptable, for example, but bit-for-bit lossless is OK. Discussion about possible transport transformations, but must have a lossless conversion from this format and back.
Q: One of the things gateways do is content transformation and the common format that is mandatory to implement.
Is there is a mechanism by which the original message can have attachments that are added by processors, e.g., that translate from english to german? A: could add them as multipart/alternative to outside the message.
Q: Adding MIME structure & complex headers will add a lot of complexity.
Summarize: shouldn't do gateways vs. keep the definition simple. If we decide to go with "simple mime", how would we support gateways?
ROOT: Should messages passed wround in CPIM-compliant
Q: do we think that we need to be able to pass around a pile of bits that can be signed:
A: Rough consensus in the room (all but 1 raised hand yes)
Q: Should CPIM specify structure of this message?
A: All think it should specify the format.
Q: Is it appropriate to say that the message contains header & body, where the body is any MIME type and the header is specified by the standard?
A: All but 1.
(Problem: if we spec headers, then the headers become religious wars of headers, which is its own body).
Q: What information should be in the header as a minimum?
Should the header set be fixed in a standard or extensible?
A: Most people want extensibility (dangerous but fun)
1.1: What information should the header contain as a minimum?
Note that this is important security information
Q: From is hard because gateway might add it. The end user recipient, what level of authenticated information do they have about who the actual recipient.
Q: For this community, while security argues for the headers in the body, it's mainly about users, and not driven by security.
Q: The security document should be outside the base document, half of implementors disagree about what should happen with the message disagrees.
Q: The point of the date field is to prevent a replay attack.
From mandatory: 50-3
To mandatory: 50-0
Date mandatory: divided, more not than yes, but no consensus
Other mandatory headers:
Message-ID: globally unique identifier not used by anyone else.
Is Derek's Http-like RFC822-like syntax a good idea?
30 thought it would be good idea (didn't ask negative question)
10 would prefer XML
Comment: If we have a constant message format, might motivate proprietary systems to use common message format even when they have proprietary protocol.
How many people we should keep presence information as it is? Or move from XML to 822-like? Room is split. Most people thought they would form an opinion after time.
Going through IMPP Common document issue list:
1. Threat models: do we need a description?
Yes, Derek will update
2. Security: common message security function
Q: what does this mean?
3: Must support multipart/signed syntax, but need not implement them.
4: Addressing: resolution was accepted
5: Is I18N properly supported?
Has further work?
6. Payload format for IMs (resolved)
7. Payload format for presence information
Need to encrypt or sign, need one.
Q: should apply same stuff to presence data?
Will be discussed on list.
Q: what is the correlation between IM and presence?
These have nothing to do with each other. ENd-to-end security is different than the security for presence.
Q: is the model for security for presence different than that for IM? A: the model is different, because you have to trust the server. Don't have the description clear enough. Q: The same argument could be made for messages through gateways. Q: Servers have to do operations on presence information that they don't need to do on messages.
8: Operation format & semantics: are they well enough defined? Q: needs checking against presence security model.
We've defined four operations in CPIM: subscribe, unsubscribe, notify, and message.
We seem to have figured out a way to exchange "secure" messages (message operation), and we have down as an action item to discuss the same thing for presence (i.e. the notify operation).
In a similar way we need to "secure" the subscribe and unsubscribe operations so that an unauthorized party cannot subscribe/unsubscribe someone.
9: Access control -- does it need definition? No comment on topic.
10: Gatewaying: explicit definition of what gateways do. Need to be somewhat explicit, at least about message gateways. Q: Needs to be more information in there, about resolution, finding the appropriate server & suggested text. Sending the instant message through gateways, might be possible, shouldn't be illegal to detect. Q: brings up interesting issue abotu whether stuff that's inside could say something about the security context. The signature will tell you something about who signed the message. The content might say something about who is expected to sign it.
11: Routing loops: Is it necessary to put this at the CPIM level? Can't put it at the transport because the only thing is common. Can solve this with received lines, need to preserve the "received lines" across gateways.
Common transport semantics? Add a layer of 'transport history' that gatways, routers and others would add but which would not be part of the signed content, could change.
Reports from the separate transport groups will be sent to the mailing list.
The goal is that the group will finish its work and then go away, hopefully before the next IETF.
Derek: wants the group to stay around as an umbrella to various transport groups.
Timeline: settled was to divide CPIM, one of which has a pointer to a document from Graham & Derek that will specify the format. After Christmas, probably early January.
Dave says that we have to resolve the issues before he can get the document done. Please type text on the way home.
Discussion on ttl vs. "received" headers, 1-5... most think we don't have enough information to decide.
Tony Hansen promised to work with Dave Crocker on the gatewaying section.
Leslie thanked everyone who worked on the issues in the hallways.
IMPP Common Messages