Subject: Revised SAP draft submitted

From: Colin Perkins <[email-masked]>
Date: Thu, 24 Feb 2000 16:45:15 +0000

I've just submitted a revision to the session announcement protocol draft,
which addresses the comments I received during working group last call.
Until it appears in the internet-draft archives, the draft is available
from:
http://www.cs.ucl.ac.uk/staff/c.perkins/internet-drafts/draft-ietf-mmusic-sap-v2-05.txt

Summary of changes since the -04 revision:
- Remove references to "client" in the text, now talks about SAP
  announcers and listeners only.
- Clarify that TTL scoping is discouraged (in favour of admin scoping)
- Clarify section on session deletion
- Remove the optional timeout field from the packet format
	- It was only used for encrypted SAP, for those cases where a
	  proxy didn't have the decryption key. 
	- We now rely on either
	 	1) the receiver of an announcement understands the payload,
		and can derive the session timeout from that (this is the
		common case)
	  or	2) the announcer sends explicit deletion packets when it
	   	stops sending the announcement
	  or	3) the receiver will timeout an announcement which hasn't
	  	been heard for some time
	  (proxies which deal with encrypted SAP can still recognize cases
	  2 and 3).
- Clarify why IPsec is not recommended for authentication.
- Update references

Colin

---

From: Dave Thaler <[email-masked]>
Date: Thu, 24 Feb 2000 11:49:06 -0800 (PST)

I still have an objection to the following language in the Introduction:
> advertisements are received by potential participants who can use the
> session description to start the tools required to participate in the
> session.

Specifically, "participants" are users (or perhaps clients), and the
advertisements should be received by SAP speakers / session directories,
NOT by participants.

Suggest something more neutral like:
  advertisements are received by other session directories so that
  potential remote participants can use the session description to ...

Likewise, Terminology section implicitly still refers to clients:
> ensuring that the recipients of
> the announcement can also be potential recipients of the session the
> announcement describes 

This language is repeated in section 3 (bottom of page 2).

Suggest something more neutral like:
  ensuring that the recipients of the announcement are within the
  scope of the session the announcement described.

Perhaps another note to the effect that:
  Ensuring that a description is not used by a potential participant
  outside the session scope is not addressed in this memo.
would be helpful as well?

The only reference to IPsec I find is in this text:
> It is to be expected that sessions may be announced by a number of
> different mechanisms, not only SAP. For example, a session description
> may placed on a web page, sent by email or conveyed in a session
> initiation protocol.  To ease interoperability with these other mechanisms,
> application level security is employed, rather than using IPsec authentication
> headers.

I don't find this to be a relevant argument.
This is an argument for making auth/encrypt be part of SDP, not SAP.
Hence, I would still argue that the SAP Auth is not sufficiently 
motivated in draft -05, and still don't see why it can't be removed.

-Dave

---

From: "Peter T. Kirstein" <[email-masked]>
Date: Thu, 24 Feb 2000 18:40:23 +0000

>http://www.cs.ucl.ac.uk/staff/c.perkins/internet-drafts/draft-ietf-mmusic-s
ap-v2-05.txt

Colin,

I really cannot see why PGP must still be mandatory and  CMS Authentication
optional. There is so much more momentum now behind CMS certificates for
many purposes. I strongly recommend that this requirement be dropped. This
is the only place where it is required; many of our server accesses now use
the certificates provided by Web browsers - which are not PGP.

Peter 

Peter

---

From: Mark Handley <[email-masked]>
Date: Thu, 24 Feb 2000 11:05:28 -0800

>motivated in draft -05, and still don't see why it can't be removed.

We need a solid way to do authentication so we need to specify
something.

I think there are two motivations for not using IPsec:

 - Very little IPsec deployment.  SAP is going to Experimental.  If it
   ever goes to Proposed Standard, we should revisit this issue, but
   right now you have to assume that most receivers don't understand
   IPsec AH.

 - No-one seems to have a clue how to do the SPI for multicast apps
   like SAP that don't have a setup phase.  Until someone explains how
   to do this, IPsec seems problematic.

But it's not clear you want to set-in-stone these arguments in the RFC
itself because they're clearly subject to change.

The real choice at this stage seems to be between SAP-level auth and
SDP-level auth.  However, the authentication mechanisms open to you
appear to be determined by the way you receive the session description
(Eg. in SIP/RTSP you can do an exchange with the sender to request a
certificate, in SAP you can't).  This it seems to me like SAP is a
better place than SDP for the authentication mechanism.

But I don't consider myself a security expert, so I'd like to hear
from someone who is.

Cheers,
	Mark

---

From: Dave Thaler <[email-masked]>
Date: Thu, 24 Feb 2000 13:00:26 -0800 (PST)

> better place than SDP for the authentication mechanism.

I would argue the reverse.  I would liken SDP to an email message
(even if carried via SAP), where you have no idea how many relays 
it's gone through, and trusting the last relay means little.
You want the email message to be signed, e.g. PGP or whatever,
so that it can be authenticated regardless of how many different
propagation methods or hops it's gone through.  For example,
consider a SAP-to-web page gateway.  The description can only
be authenticated by a recipient if it's in the SDP.

If requesting a certificate is done out of band (i.e. not part of SAP),
then I don't understand why you can't do an exchange with the
original SDP creator (which may be different from the SAP advertiser
... consider an email-to-SAP gateway...).

-Dave

---

From: Mark Handley <[email-masked]>
Date: Thu, 24 Feb 2000 15:12:25 -0800

>be authenticated by a recipient if it's in the SDP.

OK, I see your viewpoint.

In the case of SIP, there are really two authentication functions:
authenticating the payload, and authenticating who you get the request
to join the session from.  They're complementary.  

In the case of SAP, I was confusing authenticating the session with
authenticating who tells you about the session.  If the latter is not
relevant with SAP, then we don't need SAP authentication.

Either way, it looks like we do need SDP authentication.

Two questions then:

 - Are we sure we don't need any form of SAP authentication if we've
   got SDP authentication?  (probably we don't)

 - How do we go about adding authentication to SDP at this stage?
   Define an attribute?

Cheers,
	Mark

---

From: Colin Perkins <[email-masked]>
Date: Thu, 24 Feb 2000 23:09:07 +0000

>the certificates provided by Web browsers - which are not PGP.

The reasons are primarily historical: at the time the text in question was
written CMS was considerably less prevalent than it is now. 

Since we now allow a variety of payload formats, some of which may include
authentication, I wonder if we should not change the draft to state that
both authentication formats are optional?

Colin

---

From: Colin Perkins <[email-masked]>
Date: Thu, 24 Feb 2000 23:24:08 +0000

>would be helpful as well?

Okay, I'm happy with all these changes. I'll include them into the -06
draft.

Colin

---

From: Colin Perkins <[email-masked]>
Date: Thu, 24 Feb 2000 23:35:07 +0000

>be authenticated by a recipient if it's in the SDP.

One of the primary reasons for including the authentication information in
SAP, rather than SDP, is that SAP can remain independent of the format of
the data being announced.

If we use SDP level authentication, we need to specify authentication
separately for each payload format which SAP can transport. I would
prefer a single authentication scheme for all announcements.

Colin

---

From: Peter KIRSTEIN <[email-masked]>
Date: Fri, 25 Feb 2000 08:02:53 +0000

>both authentication formats are optional?
I agree.

Peter

Peter

X*********************************************************************X
* Prof Peter Kirstein		   Telephone:  +44 171 380 7286	
* Department of Computer Science   Fax:        +44 171 387 1397
* University College London        Telex:      28722
* Gower Street                     Internet:   [email-masked]
* London 
* WC1E 6BT                      
* U.K			URL    : http://www.cs.ucl.ac.uk/staff/kirstein
X*********************************************************************X