draft-ietf-mmusic-sap-v2-01.txt   draft-ietf-mmusic-sap-v2-02.txt 
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-01.txt draft-ietf-mmusic-sap-v2-02.txt
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at line 85 skipping to change at line 85
allowing those sessions to be joined. allowing those 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].
3 Session Announcement 3 Session Announcement
As noted previously, a SAP announcer periodically sends an announcement As noted previously, a SAP announcer periodically sends an announcement
packet to a well known multicast address and port. There is no rendezvous packet to a well known multicast address and port. There is no rendezvous
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
any SAP listeners - and no additional reliability is provided over the of any SAP listeners - and no additional reliability is provided
standard best-effort UDP/IP semantics. over the 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 8). although this is NOT RECOMMENDED (see section 8).
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. can also be potential recipients of the session being advertised.
There are four possiblities: There are four possiblities:
skipping to change at line 150 skipping to change at line 150
An IPv4 SAP listener SHOULD listen on the IPv4 global scope SAP address An IPv4 SAP listener SHOULD listen on the IPv4 global scope SAP address
and on the SAP addresses for each IPv4 administrative scope zone and on the SAP addresses for each IPv4 administrative scope zone
it is within. The discovery of administrative scope zones is outside it is within. The discovery of administrative scope zones is outside
the scope of this memo, but it is assumed that each SAP listener the scope of this memo, but it is assumed that each SAP listener
within a particular scope zone is aware of that scope zone. A SAP within a particular scope zone is aware of that scope zone. A SAP
listener which supports IPv6 SHOULD also listen to the IPv6 SAP addresses. listener which supports IPv6 SHOULD also listen to the IPv6 SAP addresses.
Support for directory sessions is OPTIONAL. Support for directory sessions is OPTIONAL.
The time period between repetitions of an announcement is chosen such that 3.1 Announcement Interval
the total bandwidth used by all announcements on a single SAP group remains
below a preconfigured limit. If not otherwise specified, the bandwidth
limit SHOULD be assumed to be 4000 bits per second.
Each announcer is expected to listen to other announcements in order to The time period between repetitions of an announcement is chosen
determine the total number of sessions being announced on a particular such that the total bandwidth used by all announcements on a single
group. Sessions are uniquely identified by the combination of the message SAP group remains below a preconfigured limit. If not otherwise
identifier hash and originating source fields of the SAP header. If these specified, the bandwidth limit SHOULD be assumed to be 4000 bits
fields are non-zero they form a unique identifier for the announcement, if per second.
they are zero then the entire message MUST be compared to determine
uniqueness.
Thus you should calculate the available bandwidth for your session's scope Each announcer is expected to listen to other announcements in order
by dividing the bandwidth limit by the number of other sessions being to determine the total number of sessions being announced on a particular
announced in your scope. This gives you your bandwidth allocation, which, group. Sessions are uniquely identified by the combination of the
given the size of your data packets, can be used to derive the base message identifier hash and originating source fields of the SAP
interval for announcements. That is, given a limit in bits/second (as header (note that SAP v0 clients always set the message identifier
above) and a ad_size in bytes, the base announcement interval in seconds is hash to zero, and if such an announcement is received the entire
message MUST be compared to determine uniqueness).
interval = MAX(300; (8* no_of_ads* ad_size)/limit) Announcements are made by periodic multicast to the group. The base
interval between announcements is derived from the number of announcements
being made in that group, the size of the announcement and the configured
bandwidth limit. The actual transmission time is derived from this
base interval as follows:
For every interval between announcement packets (i.e, every time you send a 1.The announcer initialises the variable tp to be the last time
packet), you must add a random value (+/- 1/3 of the base interval) to the a particular announcement was transmitted (or the current time
value used for the inter-announcement period to prevent announcement if this is the first time this announcement is to be made).
synchronisation. It is also important to keep monitoring other
announcements and adjust the base interval accordingly. 2.Given a configured bandwidth limit in bits/second and an announcement
of ad_size bytes, the base announcement interval in seconds is
interval = max(300; (8*no_of_ads*ad_size)/limit)
3.An offset is calculated based on the base announcement interval
offset = rand(interval* 2/3)-(interval/3)
4.The next transmission time for an announcement derived as
tn = tp + interval + offset
The announcer then sets a timer to expire at tn and waits. When
this timer expires, the announcement is transmitted.
If, at some time tc <tn, the no_of_ads changes (eg: if a new announcer
starts up, or an existing announcement is deleted), the announcer
SHOULD recalculate the next transmission time. If the new value
of tn is less than tc the announcement is sent immediately. Otherwise
the transmission is rescheduled for the new tn.
4 Session Deletion 4 Session Deletion
Sessions may be deleted in one of several ways: Sessions may be deleted in one of several ways:
Explicit Timeout The session description payload contains timestamp Explicit Timeout The session description payload contains timestamp
information which specifies a start and end time for the session. information which specifies a start and end time for the session.
If the current time is later than the end-time for the session, If the current time is later than the end-time for the session,
then the session is deleted from the receiver's session cache. then the session is deleted from the receiver's session cache.
If an announcement packet arrives with an end-time before the If an announcement packet arrives with an end-time before the
skipping to change at line 208 skipping to change at line 228
one hour minimum is to allow for transient network partitionings. one hour minimum is to allow for transient network partitionings.
Explicit Deletion A session deletion packet is received specifying Explicit Deletion A session deletion packet is received specifying
the version of the session to be deleted. The deletion packets the version of the session to be deleted. The deletion packets
should be ignored, unless they contain an authentication header should be ignored, unless they contain an authentication header
which authenticates correctly and matches that used to authenticate which authenticates correctly and matches that used to authenticate
the announcement which is being deleted. the announcement which is being deleted.
5 Session Modification 5 Session Modification
A pre-announced session can be modified by simply announcing the modified A pre-announced session can be modified by simply announcing the
session description. In this case, the version hash in the SAP header MUST modified session description. In this case, the version hash in
be changed to indicate to receivers that the packet contents should be the SAP header MUST be changed to indicate to receivers that the
parsed (or decrypted and parsed if it is encrypted). The session itself, packet contents should be parsed (or decrypted and parsed if it is
as distinct from the session announcement, is uniquely identified by the encrypted). The session itself, as distinct from the session announcement,
payload and not by the message identifier hash in the header. is uniquely identified by the payload and not by the message identifier
hash in the header.
The same rules apply for session modification as for session deletion: The same rules apply for session modification as for session deletion:
o Either the modified announcement must contain an authentication o Either the modified announcement must contain an authentication
header signed by the same key as the cached session announcement header signed by the same key as the cached session announcement
it is modifying, or: it is modifying, or:
o The cached session announcement must not contain an authentication o The cached session announcement must not contain an authentication
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.
v=0
o=cperkins 2890844526 2890842807 IN IP4 126.16.64.4
s=Sample directory session
m=directory 9875 SAP application/sdp
c=IN IP4 224.2.127.12/255
t=2873397496 2873404696
Figure 1: Example SDP for a directory session
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 These rules prevent an announcement having an authentication header
added by a malicious user and then being deleted using that 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 and it also prevents a denial-of-service attack by someone putting
out a spoof announcement which, due to packet loss, reaches some out a spoof announcement which, due to packet loss, reaches some
participants before the original announcement. Note that under such 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.
v=0
o=cperkins 2890844526 2890842807 IN IP4 126.16.64.4
s=Sample directory session
m=directory 9875 SAP application/sdp
c=IN IP4 224.2.127.12/255
t=2873397496 2873404696
Figure 1: Example SDP for a directory session
6 Directory Sessions 6 Directory Sessions
It is possible to announce sessions which describe other directories. It is possible to announce sessions which describe other directories.
Such directory sessions should each announce a single directory. Receivers Such directory sessions should each announce a single directory. Receivers
MUST ignore announcements which describe multiple directories. Receivers MUST ignore announcements which describe multiple directories. Receivers
SHOULD ignore non-authenticated directory sessions. SHOULD ignore non-authenticated directory sessions.
Directory sessions may be described in SDP using the media type `directory' Directory sessions may be described in SDP using the media type `directory'
with transport `SAP' (see figure 1 for example). Directory sessions with transport `SAP' (see figure 1 for example). Directory sessions
SHOULD be announced with TTL 255 and SHOULD use port 9875. Any SAP SHOULD be announced with TTL 255 and SHOULD use port 9875. Any SAP
skipping to change at line 273 skipping to change at line 294
within that directory MUST stop announcing those sessions provided within that directory MUST stop announcing those sessions provided
the deletion packet authenticates with the same key as the original the deletion packet authenticates with the same key as the original
announcement of the directory session. If the deletion packet is announcement of the directory session. If the deletion packet is
not authenticated, or is authenticated with a different key, then not authenticated, or is authenticated with a different key, then
it SHOULD be ignored. it SHOULD be ignored.
If the announcement of a directory times out, announcers of sessions If the announcement of a directory times out, announcers of sessions
within that directory SHOULD stop announcing those sessions. within that directory SHOULD stop announcing those sessions.
If the announcement of the directory is modified to use a different If the announcement of the directory is modified to use a different
address announcers of sessions within that directory MUST move their
announcement to the new directory, provided the modification packet
authenticates with the same key as the original announcement of the
directory session. If the modification packet is not authenticated,
or is authenticated with a different key, then it SHOULD be ignored.
7 Packet Format
SAP data packets have the format described in figure 2.
V: Version Number. The version number field MUST be set to 1 (SAPv2
announcements which use only SAPv1 features are backwards compatible,
those which use new features can be detected by other means,
so the SAP version number doesn't need to change).
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 header | | optional authentication data |
: .... : : .... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional timeout | | optional timeout |
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| optional payload type | | optional payload type |
+ +-+- - - - - - - - - -+ + +-+- - - - - - - - - -+
| |0| | | |0| |
+ - - - - - - - - - - - - - - - - - - - - +-+ | + - - - - - - - - - - - - - - - - - - - - +-+ |
| | | |
: payload : : payload :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Packet format Figure 2: Packet format
address announcers of sessions within that directory MUST move their
announcement to the new directory, provided the modification packet
authenticates with the same key as the original announcement of the
directory session. If the modification packet is not authenticated,
or is authenticated with a different key, then it SHOULD be ignored.
7 Packet Format
SAP data packets have the format described in figure 2.
V: Version Number. The version number field MUST be set to 1 (SAPv2
announcements which use only SAPv1 features are backwards compatible,
those which use new features can be detected by other means,
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 T: Message Type. If the T field is set to 0 this is a session announcement
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 and the timeout field MUST be of the SAP packet is encrypted and the timeout field MUST be
added to the packet header. If this bit is 0 the packet is added to the packet header. If this bit is 0 the packet is
not encrypted and the timeout MUST NOT be present. See section not encrypted and the timeout MUST NOT be present. See section
8 for details of the encryption process. 8 for details of the encryption 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
authentication data. If it is zero, no authentication header data. If it is zero, no authentication header is present.
is present.
Authentication Header 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 9 for details of the authentication process. field. See section 9 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.
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 zero. SAP announcers SHOULD NOT set the message identifier hash to
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 line 392 skipping to change at line 413
decrypt the announcement. A SAP listener which is capable of decrypt the announcement. A SAP listener which is capable of
decrypting the announcement MUST determine when to timeout the decrypting the announcement MUST determine when to timeout the
session based on the payload information. session based on the payload information.
The value is an unsigned quantity giving the NTP time [8] in The value is an unsigned quantity giving the NTP time [8] in
seconds at which time the session is timed out. It is in network seconds at which time the session is timed out. It is in network
byte order. byte order.
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 optionally 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 payload type field is a MIME content type specifier, describing
the format of the payload. This is a variable length ASCII text the format of the payload. This is a variable length ASCII text
string, followed by a single zero byte (ASCII NUL). The payload type string, followed by a single zero byte (ASCII NUL). The payload type
SHOULD be included in all packets. If the payload type is `application/sdp' SHOULD be included in all packets. If the payload type is `application/sdp'
both the payload type and its terminating zero byte MAY be omitted, both the payload type and its terminating zero byte MAY be omitted,
although this is intended for backwards compatibility with SAP v1 although this is 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
skipping to change at line 422 skipping to change at line 442
for this reason, 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 If the packet is a session deletion packet, the payload contains
a session deletion message. If the payload format is `application/sdp' a session deletion message. If the payload format is `application/sdp'
the deletion message is a single SDP line consisting of the origin the deletion message is a single SDP line consisting of the origin
field of the 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
do not get fragmented by the underlying network. Fragmentation has a loss packets do not get fragmented by the underlying network. Fragmentation
multiplier effect, which is known to significantly affect the reliability has a loss multiplier effect, which is known to significantly affect
of announcements. It is RECOMMENDED that SAP packets are smaller than the reliability of announcements. It is RECOMMENDED that SAP packets
1kByte in length, although if it is known that announcements will use a are smaller than 1kByte in length, although if it is known that announcements
network with a smaller MTU than this, then that SHOULD be used as the
maximum recommended packet size. will use a network with a smaller MTU than this, then that SHOULD
be used as the maximum recommended packet size.
8 Encrypted Announcements 8 Encrypted Announcements
An announcement is received by all listeners in the scope to which An announcement is received by all listeners in the scope to which
it is sent. If an announcement is encrypted, and many of the receivers it is sent. If an announcement is encrypted, and many of the receivers
do not have the encryption key, there is a considerable waste of do not have the encryption key, there is a considerable waste of
bandwidth since those receivers cannot use the announcement they have bandwidth since those receivers cannot use the announcement they have
received. For this reason, the use of encrypted SAP announcements received. For this reason, the use of encrypted SAP announcements
is NOT RECOMMENDED on the global scope SAP group or on administrative is NOT RECOMMENDED on the global scope SAP group or on administrative
scope groups which may have many receivers which cannot decrypt those scope groups which may have many receivers which cannot decrypt those
skipping to change at line 492 skipping to change at line 513
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 assymetric algorithm, but then it is possible to encrypted with an assymetric 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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1 |P| Auth | |
+-+-+-+-+-+-+-+-+ |
| Format specific authentication subheader |
: .................. :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of the authentication header
9 Authenticated Announcements 9 Authenticated Announcements
The authentication header can be used for two purposes: The authentication header can be used for two purposes:
o Verification that changes to a session description or deletion o Verification that changes to a session description or deletion
of a session are permitted. of a session are permitted.
o Authentication of the identity of the session creator. 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 However, under such circumstances, the session originator may still
be authenticated to be the same as the session originator of previous be authenticated to be the same as the session originator of previous
sessions claiming to be from the same person. This may or may not sessions claiming to be from the same person. This may or may not
be sufficient depending on the purpose of the session and the people be sufficient depending on the purpose of the session and the people
involved. involved.
Clearly the key used in the authentication header 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
headers are self-describing, but their precise format depends on the data in the header is self-describing, but the precise format depends
authentication mechanism in use. The generic format of the Authentication on the authentication mechanism in use. The generic format of the
Header is given in figure 3. The structure of the Format Specific authentication data is given in figure 3. The structure of the format
Authentication Subheader, using both the PGP and the CMS formats, specific authentication subheader, using both the PGP and the CMS
is discussed in sections 9.1 and 9.2 respectively. formats, is discussed in sections 9.1 and 9.2 respectively.
Version Number, V: The version number of the authentication header 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1 |P| Auth | |
+-+-+-+-+-+-+-+-+ |
| Format specific authentication subheader |
: .................. :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of the authentication data in the SAP header
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 data in the authentication header Padding Bit, P: If necessary the authentication data is padded
is padded to be a multiple of 32 bits and the padding bit is to be a multiple of 32 bits and the padding bit is set. In
set. In this case the last byte of the authentication header this case the last byte of the authentication data contains the
contains the number of padding bytes (including the last byte) number of padding bytes (including the last byte) that must be
that must be discarded. discarded.
Authentication Type, Auth: The authentication type is a 4 bit encoded Authentication Type, Auth: The authentication type is a 4 bit encoded
field that denotes the authentication infrastructure the sender field that denotes the authentication infrastructure the sender
expects the recipients to use to check the authenticity and integrity expects the recipients to use to check the authenticity and integrity
of the information. This defines the format of the authentication of the information. This defines the format of the authentication
subheader and can take the values: 0 = PGP format, 1 = CMS subheader and can take the values: 0 = PGP format, 1 = CMS
format. All other values are undefined and SHOULD be ignored. format. All other values are undefined and SHOULD be ignored.
If a SAP packet is to be compressed or encrypted, this MUST be done If a SAP packet is to be compressed or encrypted, this MUST be done
before the authentication is added. before the authentication is added.
The digital signature in the authentication header 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 header field excluded length MUST be set to zero and the authentication data excluded when
when calculating the digitial signature. calculating the digitial signature.
9.1 PGP Authentication 9.1 PGP Authentication
Implementations which support authentication MUST support this format. Implementations which support authentication MUST support this format.
A full description of the PGP protocol can be found in [2]. When A full description of the PGP protocol can be found in [2]. When
using PGP for SAP authentication the basic format specific authentication using PGP for SAP authentication the basic format specific authentication
subheader comprises a digital signature packet as described in [2]. subheader comprises a digital signature packet as described in [2].
The signature type MUST be 0x01 which means the signature is that The signature type MUST be 0x01 which means the signature is that
of a canonical text document. of a canonical text document.
9.2 CMS Authentication 9.2 CMS Authentication
Support for this format is OPTIONAL. Support for this format is OPTIONAL.
skipping to change at line 767 skipping to change at line 791
[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 1999. Work in progress. announcement protocol (MZAP)(, February 1999. Work in progress.
[6] R. Housley. Cryptographic message syntax. Work in progress, April [6] R. Housley. Cryptographic message syntax. Work in progress,
1999. draft-ietf-smime-cms-13.txt. April 1999. draft-ietf-smime-cms-13.txt.
[7] D. Mayer. Administratively scoped IP multicast, July 1998. RFC2365. [7] D. Mayer. Administratively scoped IP multicast, July 1998. RFC2365.
[8] D. Mills. Network time protocol version 3, March 1992. RFC1305. [8] D. Mills. Network time protocol version 3, March 1992. RFC1305.
 End of changes. 28 change blocks. 
102 lines changed or deleted 124 lines changed or added

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