Streaming Internet Messaging Attachments
draft-ietf-lemonade-streaming-13

[Ballot discuss]
So, from a joking point of view, this is both secure and deployable. Unfortunately the parts that are deployable are not secure and the parts that are secure and not deployable.

This specification recommends using S/MIME to protect the pawn tickets. I don't understand how this works - first, when the ticket is in the SIP request URI, S/MIME can't help. Second, when the pawn ticket it is a body, I don't understand how the client would know what public key to use to encrypt the data.

When S/MIME is not used, the draft mostly assumes a direct SIP connection from client to server - I am not aware of any deployments where this would happen and the SIP security model needs to deal with proxies and B2BUAs. This is discussed in the security section but the mitigations and implications are not.  The way to ensure TLS on every hop would be to use a sips URL.

Both sips URL and S/MIME are not deployable in almost every deployment where this would be used. The security consideration need to make it very clear that every proxy or B2BUA that sees the SIP message, and any device that sniffs any unencrypted SIP traffic is going to be able to access the messages.

There are plenty of ways that this system could be secured in the sense of stopping unauthorized users from listening to the messages without requiring S/MIME. For example, if the client told the imap server a hash the the SRTP key it would use, then the that was encode in the pawn ticket, then the media server verified that the key in the SRTP session matched the pawn ticket, it would result in a system that was both deployable, easy to implement, and far more secure than this. Did the WG consider any designs to secure this that were deployable?

I'm not exactly sure what to do about the above items. I'm relatively pragmatic about this and the right solution might be to just remove the stuff that no one will do, and clearly explain the limitations on the security of the stuff that is there. Another path would be to actually fix the security in some way. I look forward to others opinions on best way to get a document out the door that meets users needs, represents reality of what will be implemented, and has "good enough" security along with full explanation of limitations of "good enough"

[Ballot comment]
Section 8:

Reference to ABNF needs to be udpated.

Section 3.5 and related text should be updated to at least provide some hint about the high level actions if the media server is unable to transcode or interpret the attachements.

[Ballot discuss]
1. A Discuss for discussion in IESG:

Why is this going for informational status? It seems to me very much be a protocol specification and has lot of normative stuff.

2. I think there is a big whole in error handling, or at least insufficiently explained. The media server is capable of retrieving the attachment then is completely unable to convert the content of the file into RTP. This can be fore several reasons:
1. No RTP payload format for the content type
2. No transcoding from that media format to another that is supported.
3. The content type is supported however converting this particular file to RTP is not supported due to the complexity in making the content type robust enough for RTP transport.

I think indicating an error that there is no common format between the media server and the client seems wrong, as the issue is that the media server can't provide any media from the attachment. Can you please elaborate on how this should be handled.

[Ballot discuss]
I am concerned about the following. I did not have a lot of time to read
the document, so I'm probably missing something, but:

  If the media server is configured as an authorized user of the IMAP
  server, it SHOULD authenticate to the IMAP server using the
  credentials for that user.

this seems to be saying that the media server needs to hold credentials
for the user. The IETF has a rule, I think, against recommending
private key sharing or even group shared secrets. Isn't this breaking
against that policy?

Then again, maybe I'm missing something because the rest of the document
talks about pawn tickets, which does not seem to match with the above
text.

[Ballot discuss]
1. A Discuss for discussion in IESG:

Why is this going for informational status? It seems to me very much be a protocol specification and has lot of normative stuff.

2. I think there is a big whole in error handling, or at least insufficiently explained. The media server is capable of retrieving the attachment then is completely unable to convert the content of the file into RTP. This can be fore several reasons:
1. No RTP payload format for the content type
2. No transcoding from that media format to another that is supported.
3. The content type is supported however converting this particular file to RTP is not supported due to the complexity in making the content type robust enough for RTP transport.

I think indicating an error that there is no common format between the media server and the client seems wrong, as the issue is that the media server can't provide any media from the attachment. Can you please elaborate on how this should be handled.

[Ballot discuss]
I have reviewed draft-ietf-lemonade-streaming-10, and have one concern
that I'd like to discuss before recommending approval of the document.

The draft seems a bit thin on how the communication between the client
and the media server is secured.  Presumably, the client would like to
ensure that the media server is trustworthy (and not any random
attacker); and the media server may want to provide services only to
authorized clients.

Currently, the draft does mention S/MIME a couple of times, but that
does not sound like a realistic security mechanism for environments
envisioned in lemonade. Neither is assuming client certificates.

Could you elaborate a bit on how you're planning to (1) authenticate
the client to the media server, and (2) authenticate the media
server to the client?

[Ballot discuss]
1: The "=" signs in the play parameter values of the SIP URIs have to be escaped. Please double check the other symbols in the examples and consider pointing to the URI construction section in 3261.

2: In section 8, aren't the <>'s supposed to be literal? ("<" absolute-URI ">")

[Ballot discuss]
The security of this draft is predicated on S/MIME and SIPS. Neither of which have ever been deployed and I am told that OMA has no intention of using them. I don't know if the security ADs would be OK with the draft saying no security but if nothing else the document needs to clearly outline the attacks and risks when neither sips or S/MIME is used.

[Ballot discuss]
Section 3.7., paragraph 11:
>    The following gives an example dialog between a client and media
>    server, including a rewind request, and termination of the playback
>    by use of the escape key.

  DISCUSS: The XML in the example is invalid ( is never closed).
  Please check the other examples as well. (Let me know if you want the
  xmllint output.)

[Ballot comment]
In the Security Considerations section, last bullet item on p 24, the first media server is inconsistently referred to as either MS1 or M1.

IANA comments/questions:

- What exactly are you registering? Are you trying to register
the METADATA IMAP Capability? If so, what are the Type, Name, and
Content-type descriptions for? It would help if you specified which
registry you were trying to add this into, because it's unclear in
context.

- If you're trying to register an Access Identifier Registration
(as per draft-ncook-urlauth-accessid-01.txt), you're not
following the template. The "subject" is wrong, you're missing
the Application entry, and there is no Content-Type entry.


Upon approval of this document, IANA will make the following
assignments in the Internet Message Access Protocol (IMAP) 4
Capabilities Registry at
http://www.iana.org/assignments/imap4-capabilities

Capability Name Reference
-------------------------- ------------------
METADATA [RFC-lemonade-streaming-09]


We understand the above to be the only IANA Action for this document.

Streaming Internet Messaging Attachments
draft-ietf-lemonade-streaming-09
(Informational)

(1.a) Document Shepherd: Glenn Parsons, gparsons@nortel.com, personally
reviewed this document.  This document is ready for publication.

(1.b) Work group review: The lemonade work group provided review of this
document.  Commenters included Dave Cridland, Martijn Koster, and Alexey
Melnikov.

(1.c) Further review required: None. This document received SIP/RAI area
review by Paul Kyzivat. Eric Burger is a document contributor.

(1.d.i) Document Shepherd Comfort Level: High
(1.d.ii) Document Useful and Needed: Yes
(1.d.iii) IPR Disclosures: None known

(1.e) WG Consensus: Minor edit issues, but no substantive issues. All
edits addressed in this version.

(1.f)  There are no members with objections or concerns. There are no
threats of appeal or process issues.

(1.g) ID-nits: Check and verified with idnits 2.11.04  Some references
need to be updated (e.g., RFC 5464).  And this does not use the new RFC
5378 boilerplate -- but it does not need to at this stage.


(1.h) References: Normative and Informative are up-to-date.

(1.i) IANA Considerations: None

(1.j) ABNF: No ABNF in the document

(1.k) Document Announcement:

Technical Summary

This document describes a method for streaming multimedia attachments
received by a resource constrained and/or mobile device from an IMAP
server.  It allows such clients, which often have limits in storage
space and bandwidth, to play video and audio e-mail content.  The
document describes a profile for making use of the IMAP URLAUTH
extension (RFC 4467), the Network Announcement SIP Media Service (RFC
4240), and the Media Server Control Markup Language (RFC 5022).


Working Group Summary

There is consensus in the WG to publish this document.


Document Quality

Virtually all members of the Lemonade WG have reviewed the document, as
well as specialized review from the SIPPING work group.

The document has been checked manually and using idnits 2.11.04 , and
passed both checks.

Glenn Parsons shepherds this document, has reviewed this document, and
believes that this version is ready for forwarding to the IESG for
publication.