draft-ietf-mmusic-sap-v2-05.txt   draft-ietf-mmusic-sap-v2-06.txt 
INTERNET-DRAFT 21 February 2000 INTERNET-DRAFT 6 March 2000
Mark Handley Mark Handley
ACIRI ACIRI
Colin Perkins Colin Perkins
UCL UCL
Edmund Whelan Edmund Whelan
UCL UCL
Session Announcement Protocol Session Announcement Protocol
draft-ietf-mmusic-sap-v2-05.txt draft-ietf-mmusic-sap-v2-06.txt
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 6 skipping to change at page 2, line 6
affecting security and scalability that should be taken affecting security and scalability that should be taken
into account by implementors. into account by implementors.
1 Introduction 1 Introduction
In order to assist the advertisement of multicast multimedia conferences In order to assist the advertisement of multicast multimedia conferences
and other multicast sessions, and to communicate the relevant session and other multicast sessions, and to communicate the relevant session
setup information to prospective participants, a distributed session setup information to prospective participants, a distributed session
directory may be used. An instance of such a session directory periodically directory may be used. An instance of such a session directory periodically
multicasts packets containing a description of the session, and these multicasts packets containing a description of the session, and these
advertisements are received by potential participants who can use the advertisements are received by other session directories such that
session description to start the tools required to participate in the potential remote participants can use the session description to start
session. the tools required to participate in the session.
This memo describes the issues involved in the multicast announcement of This memo describes the issues involved in the multicast announcement
session description information and defines an announcement protocol to be of session description information and defines an announcement protocol
used. Sessions are described using the session description protocol which to be used. Sessions are described using the session description
is described in a companion memo [4]. protocol which is described in a companion memo [4].
2 Terminology 2 Terminology
A SAP announcer periodically multicasts an announcement packet to a well A SAP announcer periodically multicasts an announcement packet to a well
known multicast address and port. The announcement is multicast with the known multicast address and port. The announcement is multicast with the
same scope as the session it is announcing, ensuring that the recipients of same scope as the session it is announcing, ensuring that the recipients of
the announcement can also be potential recipients of the session the the announcement are within the scope of the session the announcement
announcement describes (bandwidth and other such constraints permitting). describes (bandwidth and other such constraints permitting). This is also
This is also important for the scalability of the protocol, as it keeps important for the scalability of the protocol, as it keeps local session
local session announcements local. announcements local.
A SAP listener learns of the multicast scopes it is within (for example, A SAP listener learns of the multicast scopes it is within (for example,
using the Multicast-Scope Zone Announcement Protocol [5]) and listens on using the Multicast-Scope Zone Announcement Protocol [5]) and listens on
the well known SAP address and port for those scopes. In this manner, it the well known SAP address and port for those scopes. In this manner, it
will eventually learn of all the sessions being announced, allowing those will eventually learn of all the sessions being announced, allowing those
sessions to be joined. sessions to be joined.
The key words `MUST', `MUST NOT', `REQUIRED', `SHALL', `SHALL NOT', The key words `MUST', `MUST NOT', `REQUIRED', `SHALL', `SHALL NOT',
`SHOULD', `SHOULD NOT', `RECOMMENDED', `MAY', and `OPTIONAL' in this `SHOULD', `SHOULD NOT', `RECOMMENDED', `MAY', and `OPTIONAL' in this
document are to be interpreted as described in [1]. document are to be interpreted as described in [1].
skipping to change at page 2, line 49 skipping to change at page 2, line 49
mechanism - the SAP announcer is not aware of the presence or absence of mechanism - the SAP announcer is not aware of the presence or absence of
any SAP listeners - and no additional reliability is provided over the any SAP listeners - and no additional reliability is provided over the
standard best-effort UDP/IP semantics. standard best-effort UDP/IP semantics.
That announcement contains a session description and SHOULD contain That announcement contains a session description and SHOULD contain
an authentication header. The session description MAY be encrypted an authentication header. The session description MAY be encrypted
although this is NOT RECOMMENDED (see section 7). although this is NOT RECOMMENDED (see section 7).
A SAP announcement is multicast with the same scope as the session A SAP announcement is multicast with the same scope as the session
it is announcing, ensuring that the recipients of the announcement it is announcing, ensuring that the recipients of the announcement
can also be potential recipients of the session being advertised. are within the scope of the session the announcement describes.
There a number of possiblities: There are a number of possiblities:
IPv4 global scope sessions use multicast addresses in the range IPv4 global scope sessions use multicast addresses in the range
224.2.128.0 - 224.2.255.255 with SAP announcements being sent 224.2.128.0 - 224.2.255.255 with SAP announcements being sent
to 224.2.127.254 (note that 224.2.127.255 is used by the obsolete to 224.2.127.254 (note that 224.2.127.255 is used by the obsolete
SAPv0 and MUST NOT be used). SAPv0 and MUST NOT be used).
IPv4 administrative scope sessions using administratively scoped IPv4 administrative scope sessions using administratively scoped
IP multicast as defined in [7]. The multicast address to be IP multicast as defined in [7]. The multicast address to be
used for announcements is the highest multicast address in the used for announcements is the highest multicast address in the
relevant administrative scope zone. For example, if the scope relevant administrative scope zone. For example, if the scope
range is 239.16.32.0 - 239.16.33.255, then 239.16.33.255 is used range is 239.16.32.0 - 239.16.33.255, then 239.16.33.255 is used
for SAP announcements. for SAP announcements.
IPv6 sessions are announced on the address FF0X:0:0:0:0:0:2:7FFE IPv6 sessions are announced on the address FF0X:0:0:0:0:0:2:7FFE
where X is the 4-bit scope value. For example, an announcement where X is the 4-bit scope value. For example, an announcement
for a link-local session assigned the address FF02:0:0:0:0:0:1234:5678, for a link-local session assigned the address FF02:0:0:0:0:0:1234:5678,
should be advertised on SAP address FF02:0:0:0:0:0:2:7FFE. should be advertised on SAP address FF02:0:0:0:0:0:2:7FFE.
Ensuring that a description is not used by a potential participant
outside the session scope is not addressed in this memo.
SAP announcements MUST be sent on port 9875 and SHOULD be sent with SAP announcements MUST be sent on port 9875 and SHOULD be sent with
an IP time-to-live of 255 (the use of TTL scoping for multicast is an IP time-to-live of 255 (the use of TTL scoping for multicast is
discouraged [7]). discouraged [7]).
If a session uses addresses in multiple administrative scope ranges, If a session uses addresses in multiple administrative scope ranges,
it is necessary for the announcer to send identical copies of the it is necessary for the announcer to send identical copies of the
announcement to each administrative scope range. It is up to the announcement to each administrative scope range. It is up to the
listeners to parse such multiple announcements as the same session listeners to parse such multiple announcements as the same session
(as identified by the SDP origin field, for example). The announcement (as identified by the SDP origin field, for example). The announcement
rate for each administrative scope range MUST be calculated separately, rate for each administrative scope range MUST be calculated separately,
skipping to change at page 4, line 8 skipping to change at page 4, line 13
SHOULD also listen to the IPv6 SAP addresses. SHOULD also listen to the IPv6 SAP addresses.
3.1 Announcement Interval 3.1 Announcement Interval
The time period between repetitions of an announcement is chosen The time period between repetitions of an announcement is chosen
such that the total bandwidth used by all announcements on a single such that the total bandwidth used by all announcements on a single
SAP group remains below a preconfigured limit. If not otherwise SAP group remains below a preconfigured limit. If not otherwise
specified, the bandwidth limit SHOULD be assumed to be 4000 bits specified, the bandwidth limit SHOULD be assumed to be 4000 bits
per second. per second.
Each announcer is expected to listen to other announcements in order to Each announcer is expected to listen to other announcements in order
determine the total number of sessions being announced on a particular to determine the total number of sessions being announced on a particular
group. Sessions are uniquely identified by the combination of the message group. Sessions are uniquely identified by the combination of the
identifier hash and originating source fields of the SAP header (note that message identifier hash and originating source fields of the SAP
SAP v0 announcers always set the message identifier hash to zero, and if header (note that SAP v0 announcers always set the message identifier
such an announcement is received the entire message MUST be compared to hash to zero, and if such an announcement is received the entire
determine uniqueness). message MUST be compared to determine uniqueness).
Announcements are made by periodic multicast to the group. The base Announcements are made by periodic multicast to the group. The base
interval between announcements is derived from the number of announcements interval between announcements is derived from the number of announcements
being made in that group, the size of the announcement and the configured being made in that group, the size of the announcement and the configured
bandwidth limit. The actual transmission time is derived from this base bandwidth limit. The actual transmission time is derived from this
interval as follows: base interval as follows:
1.The announcer initialises the variable tp to be the last time 1.The announcer initialises the variable tp to be the last time
a particular announcement was transmitted (or the current time a particular announcement was transmitted (or the current time
if this is the first time this announcement is to be made). if this is the first time this announcement is to be made).
2.Given a configured bandwidth limit in bits/second and an announcement 2.Given a configured bandwidth limit in bits/second and an announcement
of ad_size bytes, the base announcement interval in seconds is of ad_size bytes, the base announcement interval in seconds is
interval = max(300; (8*no_of_ads*ad_size)/limit)
interval =max(300; (8*no_of_ads*ad_size)/limit)
3.An offset is calculated based on the base announcement interval 3.An offset is calculated based on the base announcement interval
offset = rand(interval * 2/3)-(interval/3) offset= rand(interval* 2/3)-(interval/3)
4.The next transmission time for an announcement derived as 4.The next transmission time for an announcement derived as
tn = tp + interval + offset
tn =tp+ interval+ offset
The announcer then sets a timer to expire at tn and waits. At time The announcer then sets a timer to expire at tn and waits. At time
tn the announcer SHOULD recalculate the next transmission time. If tn the announcer SHOULD recalculate the next transmission time. If
the new value of tn is before the current time, the announcement the new value of tn is before the current time, the announcement
is sent immediately. Otherwise the transmission is rescheduled for is sent immediately. Otherwise the transmission is rescheduled for
the new tn. This reconsideration prevents transient packet bursts the new tn. This reconsideration prevents transient packet bursts
on startup and when a network partition heals. on startup and when a network partition heals.
4 Session Deletion 4 Session Deletion
skipping to change at page 5, line 46 skipping to change at page 6, line 4
header, and the session modification announcement must originate header, and the session modification announcement must originate
from the same host as the session it is modifying. from the same host as the session it is modifying.
If an announcement is received containing an authentication header If an announcement is received containing an authentication header
and the cached announcement did not contain an authentication header, and the cached announcement did not contain an authentication header,
or it contained a different authentication header, then the modified or it contained a different authentication header, then the modified
announcement MUST be treated as a new and different announcement, announcement MUST be treated as a new and different announcement,
and displayed in addition to the un-authenticated announcement. The and displayed in addition to the un-authenticated announcement. The
same should happen if a modified packet without an authentication same should happen if a modified packet without an authentication
header is received from a different source than the original announcement. header is received from a different source than the original announcement.
These rules prevent an announcement having an authentication header
added by a malicious user and then being deleted using that header,
and it also prevents a denial-of-service attack by someone putting
out a spoof announcement which, due to packet loss, reaches some
participants before the original announcement. Note that under such
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1 |A|R|T|E|C| auth len | msg id hash | | V=1 |A|R|T|E|C| auth len | msg id hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: originating source (32 or 128 bits) : : originating source (32 or 128 bits) :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional authentication data | | optional authentication data |
skipping to change at page 6, line 27 skipping to change at page 6, line 28
+ +-+- - - - - - - - - -+ + +-+- - - - - - - - - -+
| |0| | | |0| |
+ - - - - - - - - - - - - - - - - - - - - +-+ | + - - - - - - - - - - - - - - - - - - - - +-+ |
| | | |
: payload : : payload :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Packet format Figure 1: Packet format
These rules prevent an announcement having an authentication header
added by a malicious user and then being deleted using that header,
and it also prevents a denial-of-service attack by someone putting
out a spoof announcement which, due to packet loss, reaches some
participants before the original announcement. Note that under such
circumstances, being able to authenticate the message originator is circumstances, being able to authenticate the message originator is
the only way to discover which session is the correct session. the only way to discover which session is the correct session.
6 Packet Format 6 Packet Format
SAP data packets have the format described in figure 1. SAP data packets have the format described in figure 1.
V: Version Number. The version number field MUST be set to 1 (SAPv2 V: Version Number. The version number field MUST be set to 1 (SAPv2
announcements which use only SAPv1 features are backwards compatible, announcements which use only SAPv1 features are backwards compatible,
those which use new features can be detected by other means, those which use new features can be detected by other means,
so the SAP version number doesn't need to change). so the SAP version number doesn't need to change).
A: Address type. If the A bit is 0, the originating source field A: Address type. If the A bit is 0, the originating source field
contains a 32-bit IPv4 address. If the A bit is 1, the originating contains a 32-bit IPv4 address. If the A bit is 1, the originating
source contains a 128-bit IPv6 address. source contains a 128-bit IPv6 address.
R: Reserved. SAP announcers MUST set this to 0, SAP listeners MUST R: Reserved. SAP announcers MUST set this to 0, SAP listeners MUST
ignore the contents of this field. ignore the contents of this field.
T: Message Type. If the T field is set to 0 this is a session announcement T: Message Type. If the T field is set to 0 this is a session announcement
packet, if 1 this is a session deletion packet. packet, if 1 this is a session deletion packet.
E: Encryption Bit. If the encryption bit is set to 1, the payload E: Encryption Bit. If the encryption bit is set to 1, the payload
of the SAP packet is encrypted. If this bit is 0 the packet of the SAP packet is encrypted. If this bit is 0 the packet
is not encrypted. See section 7 for details of the encryption is not encrypted. See section 7 for details of the encryption
process. process.
C: Compressed bit. If the compressed bit is set to 1, the payload C: Compressed bit. If the compressed bit is set to 1, the payload
is compressed using the zlib compression algorithm [3]. If the is compressed using the zlib compression algorithm [3]. If the
payload is to be compressed and encrypted, the compression MUST payload is to be compressed and encrypted, the compression MUST
be performed first. be performed first.
Authentication Length. An 8 bit unsigned quantity giving the number Authentication Length. An 8 bit unsigned quantity giving the number
of 32 bit words following the main SAP header that contain of 32 bit words following the main SAP header that contain
authentication data. If it is zero, no authentication header is authentication data. If it is zero, no authentication header
present. is present.
Authentication data containing a digital signature of the packet, Authentication data containing a digital signature of the packet,
with length as specified by the authentication length header with length as specified by the authentication length header
field. See section 8 for details of the authentication process. field. See section 8 for details of the authentication process.
Message Identifier Hash. A 16 bit quantity that, used in combination Message Identifier Hash. A 16 bit quantity that, used in combination
with the originating source, provides a globally unique identifier with the originating source, provides a globally unique identifier
indicating the precise version of this announcement. The choice indicating the precise version of this announcement. The choice
of value for this field is not specified here, except that it of value for this field is not specified here, except that it
MUST be unique for each session announced by a particular SAP MUST be unique for each session announced by a particular SAP
announcer and it MUST be changed if the session description is announcer and it MUST be changed if the session description is
modified. modified (and a session deletion message SHOULD be sent for the
old version of the session).
Earlier versions of SAP used a value of zero to mean that the Earlier versions of SAP used a value of zero to mean that the
hash should be ignored and the payload should always be parsed. hash should be ignored and the payload should always be parsed.
This had the unfortunate side-effect that SAP announcers had This had the unfortunate side-effect that SAP announcers had
to study the payload data to determine how many unique sessions to study the payload data to determine how many unique sessions
were being advertised, making the calculation of the announcement were being advertised, making the calculation of the announcement
interval more complex that necessary. In order to decouple the interval more complex that necessary. In order to decouple the
session announcement process from the contents of those announcements, session announcement process from the contents of those announcements,
SAP announcers SHOULD NOT set the message identifier hash to SAP announcers SHOULD NOT set the message identifier hash to zero.
zero.
SAP listeners MAY silently discard messages if the message identifier SAP listeners MAY silently discard messages if the message identifier
hash is set to zero. hash is set to zero.
Originating Source. This gives the IP address of the original source Originating Source. This gives the IP address of the original source
of the message. This is an IPv4 address if the A field is set of the message. This is an IPv4 address if the A field is set
to zero, else it is an IPv6 address. The address is stored to zero, else it is an IPv6 address. The address is stored
in network byte order. in network byte order.
SAPv0 permitted the originating source to be zero if the message SAPv0 permitted the originating source to be zero if the message
skipping to change at page 7, line 58 skipping to change at page 8, line 12
SAP listeners MAY silently discard packets with the originating SAP listeners MAY silently discard packets with the originating
source set to zero. source set to zero.
The header is followed by an optional payload type field and the The header is followed by an optional payload type field and the
payload data itself. If the E or C bits are set in the header both payload data itself. If the E or C bits are set in the header both
the payload type and payload are encrypted and/or compressed. the payload type and payload are encrypted and/or compressed.
The payload type field is a MIME content type specifier, describing the The payload type field is a MIME content type specifier, describing the
format of the payload. This is a variable length ASCII text string, format of the payload. This is a variable length ASCII text string,
followed by a single zero byte (ASCII NUL). The payload type SHOULD be followed by a single zero byte (ASCII NUL). The payload type SHOULD be
included in all packets. If the payload type is `application/sdp' included in all packets. If the payload type is `application/sdp' both the
both the payload type and its terminating zero byte MAY be omitted, payload type and its terminating zero byte MAY be omitted, although this is
although this is intended for backwards compatibility with SAP v1 intended for backwards compatibility with SAP v1 listeners only.
listeners only.
The absence of a payload type field may be noted since the payload The absence of a payload type field may be noted since the payload
section of such a packet will start with an SDP `v=0' field, which section of such a packet will start with an SDP `v=0' field, which
is not a legal MIME content type specifier. is not a legal MIME content type specifier.
All implementations MUST support payloads of type `application/sdp' [4]. All implementations MUST support payloads of type `application/sdp'
Other formats MAY be supported although since there is no negotiation in [4]. Other formats MAY be supported although since there is no negotiation
SAP an announcer which chooses to use a session description format other in SAP an announcer which chooses to use a session description format
than SDP cannot know that the listeners are able to understand the other than SDP cannot know that the listeners are able to understand
announcement. A proliferation of payload types in announcements has the the announcement. A proliferation of payload types in announcements
potential to lead to severe interoperability problems, and for this reason, has the potential to lead to severe interoperability problems, and
the use of non-SDP payloads is NOT RECOMMENDED. for this reason, the use of non-SDP payloads is NOT RECOMMENDED.
If the packet is an announcement packet, the payload contains a session If the packet is an announcement packet, the payload contains a session
description. description.
If the packet is a session deletion packet, the payload contains a session If the packet is a session deletion packet, the payload contains
deletion message. If the payload format is `application/sdp' the deletion a session deletion message. If the payload format is `application/sdp'
message is a single SDP line consisting of the origin field of the the deletion message is a single SDP line consisting of the origin
announcement to be deleted. field of the announcement to be deleted.
It is desirable for the payload to be sufficiently small that SAP packets It is desirable for the payload to be sufficiently small that SAP packets
do not get fragmented by the underlying network. Fragmentation has a loss do not get fragmented by the underlying network. Fragmentation has a loss
multiplier effect, which is known to significantly affect the reliability multiplier effect, which is known to significantly affect the reliability
of announcements. It is RECOMMENDED that SAP packets are smaller than of announcements. It is RECOMMENDED that SAP packets are smaller than
1kByte in length, although if it is known that announcements will use a 1kByte in length, although if it is known that announcements will use a
network with a smaller MTU than this, then that SHOULD be used as the network with a smaller MTU than this, then that SHOULD be used as the
maximum recommended packet size. maximum recommended packet size.
7 Encrypted Announcements 7 Encrypted Announcements
skipping to change at page 9, line 10 skipping to change at page 9, line 18
details using another mechanism. There are, however, certain scenarios details using another mechanism. There are, however, certain scenarios
where encrypted announcements may be useful. For this reason, the where encrypted announcements may be useful. For this reason, the
encryption bit is included in the SAP header to allow experimentation encryption bit is included in the SAP header to allow experimentation
with encrypted announcements. with encrypted announcements.
This memo does not specify details of the encryption algorithm to This memo does not specify details of the encryption algorithm to
be used or the means by which keys are generated and distributed. be used or the means by which keys are generated and distributed.
An additional specification should define these, if it is desired An additional specification should define these, if it is desired
to use encrypted SAP. to use encrypted SAP.
Note that if an encrypted announcement is being announced via a proxy, then Note that if an encrypted announcement is being announced via a proxy,
there may be no way for the proxy to discover that the announcement has then there may be no way for the proxy to discover that the announcement
been superseded, and so it may continue to relay the old announcement in has been superseded, and so it may continue to relay the old announcement
addition to the new announcement. SAP provides no mechanism to chain in addition to the new announcement. SAP provides no mechanism to
modified encrypted announcements, so it is advisable to announce the chain modified encrypted announcements, so it is advisable to announce
unmodified session as deleted for a short time after the modification has the unmodified session as deleted for a short time after the modification
occurred. This does not guarantee that all proxies have deleted the has occurred. This does not guarantee that all proxies have deleted
session, and so receivers of encrypted sessions should be prepared to the session, and so receivers of encrypted sessions should be prepared
discard old versions of session announcements that they may receive. In to discard old versions of session announcements that they may receive.
most cases however, the only stateful proxy will be local to (and known to) In most cases however, the only stateful proxy will be local to (and
the sender, and an additional (local-area) protocol involving a handshake known to) the sender, and an additional (local-area) protocol involving
for such session modifications can be used to avoid this problem. a handshake for such session modifications can be used to avoid this
problem.
Session announcements that are encrypted with a symmetric algorithm Session announcements that are encrypted with a symmetric algorithm
may allow a degree of privacy in the announcement of a session, but may allow a degree of privacy in the announcement of a session, but
it should be recognised that a user in possession of such a key can it should be recognised that a user in possession of such a key can
pass it on to other users who should not be in possession of such pass it on to other users who should not be in possession of such
a key. Thus announcements to such a group of key holders cannot a key. Thus announcements to such a group of key holders cannot
be assumed to have come from an authorised key holder unless there be assumed to have come from an authorised key holder unless there
is an appropriate authentication header signed by an authorised key is an appropriate authentication header signed by an authorised key
holder. In addition the recipients of such encrypted announcements holder. In addition the recipients of such encrypted announcements
cannot be assumed to only be authorised key holders. Such encrypted cannot be assumed to only be authorised key holders. Such encrypted
skipping to change at page 9, line 46 skipping to change at page 10, line 5
of the session to pass on encryption keys to un-authorised users. of the session to pass on encryption keys to un-authorised users.
However it is likely that keys used for the session tools will be However it is likely that keys used for the session tools will be
more short lived than those used for session directories. more short lived than those used for session directories.
Similar considerations should apply when session announcements are Similar considerations should apply when session announcements are
encrypted with an asymmetric algorithm, but then it is possible to encrypted with an asymmetric algorithm, but then it is possible to
restrict the possessor(s) of the private key, so that announcements restrict the possessor(s) of the private key, so that announcements
to a key-holder group can not be made, even if one of the untrusted to a key-holder group can not be made, even if one of the untrusted
members of the group proves to be un-trustworthy. members of the group proves to be un-trustworthy.
8 Authenticated Announcements
The authentication header can be used for two purposes:
o Verification that changes to a session description or deletion
of a session are permitted.
o Authentication of the identity of the session creator.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1 |P| Auth | | | V=1 |P| Auth | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Format specific authentication subheader | | Format specific authentication subheader |
: .................. : : .................. :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of the authentication data in the SAP header Figure 2: Format of the authentication data in the SAP header
8 Authenticated Announcements
The authentication header can be used for two purposes:
o Verification that changes to a session description or deletion
of a session are permitted.
o Authentication of the identity of the session creator.
In some circumstances only verification is possible because a certificate In some circumstances only verification is possible because a certificate
signed by a mutually trusted person or authority is not available. signed by a mutually trusted person or authority is not available.
However, under such circumstances, the session originator may still be However, under such circumstances, the session originator may still
authenticated to be the same as the session originator of previous sessions be authenticated to be the same as the session originator of previous
claiming to be from the same person. This may or may not be sufficient sessions claiming to be from the same person. This may or may not
depending on the purpose of the session and the people involved. be sufficient depending on the purpose of the session and the people
involved.
Clearly the key used for the authentication should not be trusted Clearly the key used for the authentication should not be trusted
to belong to the session originator unless it has been separately to belong to the session originator unless it has been separately
authenticated by some other means, such as being certified by a trusted authenticated by some other means, such as being certified by a trusted
third party. Such certificates are not normally included in an SAP third party. Such certificates are not normally included in an SAP
header because they take more space than can normally be afforded header because they take more space than can normally be afforded
in an SAP packet, and such verification must therefore take place in an SAP packet, and such verification must therefore take place
by some other mechanism. However, as certified public keys are normally by some other mechanism. However, as certified public keys are normally
locally cached, authentication of a particular key only has to take locally cached, authentication of a particular key only has to take
place once, rather than every time the session directory retransmits place once, rather than every time the session directory retransmits
the announcement. the announcement.
SAP is not tied to any single authentication mechanism. Authentication SAP is not tied to any single authentication mechanism. Authentication
data in the header is self-describing, but the precise format depends data in the header is self-describing, but the precise format depends
on the authentication mechanism in use. The generic format of the on the authentication mechanism in use. The generic format of the
authentication data is given in figure 2. The structure of the format authentication data is given in figure 2. The structure of the format
specific authentication subheader, using both the PGP and the CMS specific authentication subheader, using both the PGP and the CMS
formats, is discussed in sections 8.1 and 8.2 respectively. formats, is discussed in sections 8.1 and 8.2 respectively. Additional
formats may be added in future.
Version Number, V: The version number of the authentication format Version Number, V: The version number of the authentication format
specified by this memo is 1. specified by this memo is 1.
Padding Bit, P: If necessary the authentication data is padded Padding Bit, P: If necessary the authentication data is padded
to be a multiple of 32 bits and the padding bit is set. In to be a multiple of 32 bits and the padding bit is set. In
this case the last byte of the authentication data contains the this case the last byte of the authentication data contains the
number of padding bytes (including the last byte) that must be number of padding bytes (including the last byte) that must be
discarded. discarded.
skipping to change at page 11, line 18 skipping to change at page 11, line 29
before the authentication is added. before the authentication is added.
The digital signature in the authentication data MUST be calculated The digital signature in the authentication data MUST be calculated
over the entire packet, including the header. The authentication over the entire packet, including the header. The authentication
length MUST be set to zero and the authentication data excluded when length MUST be set to zero and the authentication data excluded when
calculating the digital signature. calculating the digital signature.
It is to be expected that sessions may be announced by a number of It is to be expected that sessions may be announced by a number of
different mechanisms, not only SAP. For example, a session description different mechanisms, not only SAP. For example, a session description
may placed on a web page, sent by email or conveyed in a session may placed on a web page, sent by email or conveyed in a session
initiation protocol. To ease interoperability with these other mechanisms, initiation protocol. To ease interoperability with these other
application level security is employed, rather than using IPsec authentication mechanisms, application level security is employed, rather than
headers. using IPsec authentication headers.
8.1 PGP Authentication 8.1 PGP Authentication
Implementations which support authentication MUST support this format. A A full description of the PGP protocol can be found in [2]. When using PGP
full description of the PGP protocol can be found in [2]. When using PGP
for SAP authentication the basic format specific authentication subheader for SAP authentication the basic format specific authentication subheader
comprises a digital signature packet as described in [2]. The signature comprises a digital signature packet as described in [2]. The signature
type MUST be 0x01 which means the signature is that of a canonical text type MUST be 0x01 which means the signature is that of a canonical text
document. document.
8.2 CMS Authentication 8.2 CMS Authentication
Support for this format is OPTIONAL.
A full description of the Cryptographic Message Syntax can be found A full description of the Cryptographic Message Syntax can be found
in [6]. The format specific authentication subheader will, in the in [6]. The format specific authentication subheader will, in the
CMS case, have an ASN.1 ContentInfo type with the ContentType being CMS case, have an ASN.1 ContentInfo type with the ContentType being
signedData. signedData.
Use is made of the option available in PKCS#7 to leave the content itself Use is made of the option available in PKCS#7 to leave the content
blank as the content which is signed is already present in the packet. itself blank as the content which is signed is already present in
Inclusion of it within the SignedData type would duplicate this data and the packet. Inclusion of it within the SignedData type would duplicate
increase the packet length unnecessarily. In addition this allows this data and increase the packet length unnecessarily. In addition
recipients with either no interest in the authentication, or with no this allows recipients with either no interest in the authentication,
mechanism for checking it, to more easily skip the authentication or with no mechanism for checking it, to more easily skip the authentication
information. information.
There SHOULD be only one signerInfo and related fields corresponding There SHOULD be only one signerInfo and related fields corresponding
to the originator of the SAP announcement. The signingTime SHOULD to the originator of the SAP announcement. The signingTime SHOULD
be present as a signedAttribute. However, due to the strict size be present as a signedAttribute. However, due to the strict size
limitations on the size of SAP packets, certificates and CRLs SHOULD limitations on the size of SAP packets, certificates and CRLs SHOULD
NOT be included in the signedData structure. It is expected that NOT be included in the signedData structure. It is expected that
users of the protocol will have other methods for certificate and users of the protocol will have other methods for certificate and
CRL distribution. CRL distribution.
skipping to change at page 13, line 6 skipping to change at page 13, line 13
new announcements, strips off the original authentication header, new announcements, strips off the original authentication header,
modifies the session description, adds a new authentication header modifies the session description, adds a new authentication header
and re-announces the session. If a rule was imposed that such spoof and re-announces the session. If a rule was imposed that such spoof
announcements were ignored, then if packet loss or late starting announcements were ignored, then if packet loss or late starting
of a session directory instance caused the original announcement to of a session directory instance caused the original announcement to
fail to arrive at a site, but the spoof announcement did so, this fail to arrive at a site, but the spoof announcement did so, this
would then prevent the original announcement from being accepted at would then prevent the original announcement from being accepted at
that site. that site.
A similar denial-of-service attack is possible if a session announcement A similar denial-of-service attack is possible if a session announcement
receiver relies completely on the originating source and hash fields receiver relies completely on the originating source and hash fields to
to indicate change, and fails to parse the remainder of announcements indicate change, and fails to parse the remainder of announcements for
for which it has seen the origin/hash combination before. which it has seen the origin/hash combination before.
A denial of service attack is possible from a malicious site close A denial of service attack is possible from a malicious site close
to a legitimate site which is making a session announcement. This to a legitimate site which is making a session announcement. This
can happen if the malicious site floods the legitimate site with can happen if the malicious site floods the legitimate site with
huge numbers of (illegal) low TTL announcements describing high TTL huge numbers of (illegal) low TTL announcements describing high TTL
sessions. This may reduce the session announcement rate of the legitimate sessions. This may reduce the session announcement rate of the legitimate
announcement to below a tenth of the rate expected at remote sites announcement to below a tenth of the rate expected at remote sites
and therefore cause the session to time out. Such an attack is likely and therefore cause the session to time out. Such an attack is likely
to be easily detectable, and we do not provide any mechanism here to be easily detectable, and we do not provide any mechanism here
to prevent it. to prevent it.
skipping to change at page 15, line 34 skipping to change at page 15, line 34
References References
[1] S. Bradner. Key words for use in RFCs to indicate requirement levels, [1] S. Bradner. Key words for use in RFCs to indicate requirement levels,
March 1997. RFC2119. March 1997. RFC2119.
[2] J. Callas, L. Donnerhacke, H. Finney, and R. Thayer. OpenPGP message [2] J. Callas, L. Donnerhacke, H. Finney, and R. Thayer. OpenPGP message
format, November 1998. RFC2440. format, November 1998. RFC2440.
[3] P. Deutsch and J.-L. Gailly. Zlib compressed data format specification [3] P. Deutsch and J.-L. Gailly. Zlib compressed data format specification
version 3.3, May 1996. RFC1950. version 3.3, May 1996. RFC1950.
[4] M. Handley and V. Jacobson. SDP: Session Description Protocol, April [4] M. Handley and V. Jacobson. SDP: Session Description Protocol, April
1998. RFC2327. 1998. RFC2327.
[5] M. Handley, D. Thaler, and R. Kermode. Multicast-scope zone [5] M. Handley, D. Thaler, and R. Kermode. Multicast-scope zone
announcement protocol (MZAP), February 2000, RFC2776. announcement protocol (MZAP), February 2000. RFC2776.
[6] R. Housley. Cryptographic message syntax, June 1999. RFC2630. [6] R. Housley. Cryptographic message syntax, June 1999. RFC2630.
[7] D. Mayer. Administratively scoped IP multicast, July 1998. RFC2365. [7] D. Mayer. Administratively scoped IP multicast, July 1998. RFC2365.
 End of changes. 35 change blocks. 
105 lines changed or deleted 110 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/