draft-ietf-xcon-bfcp-connection-04.txt   draft-ietf-xcon-bfcp-connection-05.txt 
XCON Working Group G. Camarillo XCON Working Group G. Camarillo
Internet-Draft Ericsson Internet-Draft Ericsson
Expires: September 4, 2007 March 3, 2007 Expires: January 6, 2008 July 5, 2007
Connection Establishment in the Binary Floor Control Protocol (BFCP) Connection Establishment in the Binary Floor Control Protocol (BFCP)
draft-ietf-xcon-bfcp-connection-04.txt draft-ietf-xcon-bfcp-connection-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 4, 2007. This Internet-Draft will expire on January 6, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document specifies how a Binary Floor Control Protocol (BFCP) This document specifies how a Binary Floor Control Protocol (BFCP)
client establishes a connection to a BFCP floor control server client establishes a connection to a BFCP floor control server
outside the context of an offer/answer exchange. Client and server outside the context of an offer/answer exchange. Client and server
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. TCP Connection Establishment . . . . . . . . . . . . . . . . . 3 3. TCP Connection Establishment . . . . . . . . . . . . . . . . . 3
4. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Certificate-based Server Authentication . . . . . . . . . 5 5.1. Certificate-based Server Authentication . . . . . . . . . 5
5.2. Client Authentication based on a Pre-shared Secret . . . . 6 5.2. Client Authentication based on a Pre-shared Secret . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 10
1. Introduction 1. Introduction
As discussed in the BFCP (Binary Floor Control Protocol) As discussed in the BFCP (Binary Floor Control Protocol)
specification [9], a given BFCP client needs a set of data in order specification [RFC4582], a given BFCP client needs a set of data in
to establish a BFCP connection to a floor control server. These data order to establish a BFCP connection to a floor control server.
include the transport address of the server, the conference These data include the transport address of the server, the
identifier, and the user identifier. conference identifier, and the user identifier.
Once a client obtains this information, it needs to establish a BFCP Once a client obtains this information, it needs to establish a BFCP
connection to the floor control server. The way this connection is connection to the floor control server. The way this connection is
established depends on the context of the client and the floor established depends on the context of the client and the floor
control server. How to establish such a connection in the context of control server. How to establish such a connection in the context of
an SDP (Session Description Protocol) [8] offer/answer [3] exchange an SDP (Session Description Protocol) [RFC4566] offer/answer
between a client and a floor control server is specified in RFC 4583 [RFC3264] exchange between a client and a floor control server is
[10]. This document specifies how a client establishes a connection specified in RFC 4583 [RFC4583]. This document specifies how a
to a floor control server outside the context of an SDP offer/answer client establishes a connection to a floor control server outside the
exchange. context of an SDP offer/answer exchange.
BFCP entities establishing a connection outside an SDP offer/answer BFCP entities establishing a connection outside an SDP offer/answer
exchange need different authentication mechanisms than entities using exchange need different authentication mechanisms than entities using
offer/answer exchanges. This is because offer/answer exchanges offer/answer exchanges. This is because offer/answer exchanges
provide parties with an initial integrity-protected channel that provide parties with an initial integrity-protected channel that
clients and floor control servers can use to exchange the clients and floor control servers can use to exchange the
fingerprints of their self-signed certificates. Outside the offer/ fingerprints of their self-signed certificates. Outside the offer/
answer model, such a channel is not typically available. This answer model, such a channel is not typically available. This
document specifies how to authenticate clients using PSK (Pre-Shared document specifies how to authenticate clients using PSK (Pre-Shared
Key)-TLS (Transport Layer Security) [6] and how to authenticate Key)-TLS (Transport Layer Security) [RFC4279] and how to authenticate
servers using server certificates. servers using server certificates.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as document are to be interpreted as described in [RFC2119].
described in BCP 14, RFC 2119 [1] and indicate requirement levels for
compliant implementations.
3. TCP Connection Establishment 3. TCP Connection Establishment
As stated in Section 1, a given BFCP client needs a set of data in As stated in Section 1, a given BFCP client needs a set of data in
order to establish a BFCP connection to a floor control server. order to establish a BFCP connection to a floor control server.
These data include the transport address of the server, the These data include the transport address of the server, the
conference identifier, and the user identifier. It is outside the conference identifier, and the user identifier. It is outside the
scope of this document to specify how a client obtains this scope of this document to specify how a client obtains this
information. This document assumes that the client obtains this information. This document assumes that the client obtains this
information using an out-of-band method. information using an out-of-band method.
skipping to change at page 4, line 18 skipping to change at page 4, line 16
If the client is provided with the floor control server's host name If the client is provided with the floor control server's host name
instead of with its IP address, the client MUST perform a DNS lookup instead of with its IP address, the client MUST perform a DNS lookup
in order to resolve the host name into an IP address. Clients in order to resolve the host name into an IP address. Clients
eventually perform an A or AAAA DNS lookup (or both) on the host eventually perform an A or AAAA DNS lookup (or both) on the host
name. name.
In order to translate the target to the corresponding set of IP In order to translate the target to the corresponding set of IP
addresses, IPv6-only or dual-stack clients MUST use name resolution addresses, IPv6-only or dual-stack clients MUST use name resolution
functions that implement the Source and Destination Address Selection functions that implement the Source and Destination Address Selection
algorithms specified in RFC3484 [5] (on many hosts that support IPv6, algorithms specified in [RFC3484] (on many hosts that support IPv6,
APIs like getaddrinfo() provide this functionality and subsume APIs like getaddrinfo() provide this functionality and subsume
existing APIs like gethostbyname().) existing APIs like gethostbyname().)
The advantage of the additional complexity is that this technique The advantage of the additional complexity is that this technique
will output an ordered list of IPv6/IPv4 destination addresses based will output an ordered list of IPv6/IPv4 destination addresses based
on the relative merits of the corresponding source/destination pairs. on the relative merits of the corresponding source/destination pairs.
This will result in the selection of a preferred destination address. This will result in the selection of a preferred destination address.
However, the Source and Destination Selection algorithms of [5] are However, the Source and Destination Selection algorithms of [RFC3484]
dependent on broad operating system support and uniform are dependent on broad operating system support and uniform
implementation of the application programming interfaces that implementation of the application programming interfaces that
implement this behavior. implement this behavior.
Developers should carefully consider the issues described by Roy Developers should carefully consider the issues described by Roy
et al. [12] with respect to address resolution delays and address et al. [I-D.ietf-v6ops-onlinkassumption] with respect to address
selection rules. For example, implementations of getaddrinfo() resolution delays and address selection rules. For example,
may return address lists containing IPv6 global addresses at the implementations of getaddrinfo() may return address lists
top of the list and IPv4 addresses at the bottom, even when the containing IPv6 global addresses at the top of the list and IPv4
host is only configured with an IPv6 local scope (e.g., link- addresses at the bottom, even when the host is only configured
local) and an IPv4 address. This will, of course, introduce a with an IPv6 local scope (e.g., link- local) and an IPv4 address.
delay in completing the connection. This will, of course, introduce a delay in completing the
connection.
The BFCP specification [9] describes a number of situations when the The BFCP specification [RFC4582] describes a number of situations
TCP connection between a client and the floor control server needs to when the TCP connection between a client and the floor control server
be reestablished. However, that specification does not describe the needs to be reestablished. However, that specification does not
reestablishment process because this process depends on how the describe the reestablishment process because this process depends on
connection was established in the first place. how the connection was established in the first place.
When the existing TCP connection is closed following the rules in RFC When the existing TCP connection is closed following the rules in
4582 [9], the client SHOULD reestablish the connection towards the [RFC4582], the client SHOULD reestablish the connection towards the
floor control server. If a TCP connection cannot deliver a BFCP floor control server. If a TCP connection cannot deliver a BFCP
message from the client to the floor control server and times out, message from the client to the floor control server and times out,
the client SHOULD reestablish the TCP connection. the client SHOULD reestablish the TCP connection.
4. TLS Usage 4. TLS Usage
All BFCP entities implement TLS [7] and SHOULD use it in all their [RFC4582] requires that all BFCP entities implement TLS [RFC4346] and
connections. TLS provides integrity and replay protection, and recommends that they use it in all their connections. TLS provides
optional confidentiality. The floor control server MUST always act integrity and replay protection, and optional confidentiality. The
as the TLS server. floor control server MUST always act as the TLS server.
A floor control server that receives a BFCP message over TCP (no TLS) A floor control server that receives a BFCP message over TCP (no TLS)
can request the use of TLS by generating an Error message with an SHOULD request the use of TLS by generating an Error message with an
Error code with a value of 9 (Use TLS). Error code with a value of 9 (Use TLS).
5. Authentication 5. Authentication
BFCP supports client authentication based on pre-shared secrets and BFCP supports client authentication based on pre-shared secrets and
server authentication based on server certificates. server authentication based on server certificates.
5.1. Certificate-based Server Authentication 5.1. Certificate-based Server Authentication
At TLS connection establishment, the floor control server MUST At TLS connection establishment, the floor control server MUST
present its certificate to the client. The certificate provided at present its certificate to the client. The certificate provided at
the TLS-level MUST either be directly signed by one of the other the TLS-level MUST either be directly signed by one of the other
party's trust anchors or be validated using a certification path that party's trust anchors or be validated using a certification path that
terminates at one of the other party's trust anchors [4]. terminates at one of the other party's trust anchors [RFC3280].
A client establishing a connection to a server knows the server's A client establishing a connection to a server knows the server's
hostname or IP address. If the client knows the server's hostname, hostname or IP address. If the client knows the server's hostname,
the client MUST check it against the server's identity as presented the client MUST check it against the server's identity as presented
in the server's Certificate message, in order to prevent man-in-the- in the server's Certificate message, in order to prevent man-in-the-
middle attacks. middle attacks.
If a subjectAltName extension of type dNSName is present, that MUST If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the subjectAltName Certification Authorities are encouraged to use the subjectAltName
instead. instead.
Matching is performed using the matching rules specified by RFC 3280 Matching is performed using the matching rules specified by
[4]. If more than one identity of a given type is present in the [RFC3280]. If more than one identity of a given type is present in
certificate (e.g., more than one dNSName name), a match in any one of the certificate (e.g., more than one dNSName name), a match in any
the set is considered acceptable. Names in Common Name fields may one of the set is considered acceptable. Names in Common Name fields
contain the wildcard character *, which is considered to match any may contain the wildcard character *, which is considered to match
single domain name component or component fragment (e.g., *.a.com any single domain name component or component fragment (e.g., *.a.com
matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but
not bar.com). not bar.com).
If the client knows the server's IP address, the iPAddress If the client does not know the server's hostname and contacts the
server directly using the server's IP address, the iPAddress
subjectAltName must be present in the certificate and must exactly subjectAltName must be present in the certificate and must exactly
match the IP address known to the client. match the IP address known to the client.
If the hostname or IP address known to the client does not match the If the hostname or IP address known to the client does not match the
identity in the certificate, user oriented clients MUST either notify identity in the certificate, user oriented clients MUST either notify
the user (clients MAY give the user the opportunity to continue with the user (clients MAY give the user the opportunity to continue with
the connection in any case) or terminate the connection with a bad the connection in any case) or terminate the connection with a bad
certificate error. Automated clients MUST log the error to an certificate error. Automated clients MUST log the error to an
appropriate audit log (if available) and SHOULD terminate the appropriate audit log (if available) and SHOULD terminate the
connection (with a bad certificate error). Automated clients MAY connection (with a bad certificate error). Automated clients MAY
provide a configuration setting that disables this check, but MUST provide a configuration setting that disables this check, but MUST
provide a setting which enables it. provide a setting which enables it.
5.2. Client Authentication based on a Pre-shared Secret 5.2. Client Authentication based on a Pre-shared Secret
Client authentication is based on a pre-shared secret between client Client authentication is based on a pre-shared secret between client
and server. Authentication is performed using PSK-TLS [6]. and server. Authentication is performed using PSK-TLS [RFC4279].
The BFCP specification mandates support for the The BFCP specification mandates support for the
TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite. Additionally, clients and TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite. Additionally, clients and
servers supporting this specification MUST support the servers supporting this specification MUST support the
TLS_RSA_PSK_WITH_AES_128_CBC_SHA ciphersuite as well. TLS_RSA_PSK_WITH_AES_128_CBC_SHA ciphersuite as well.
6. Security Considerations 6. Security Considerations
Client and server authentication as specified in this document are Client and server authentication as specified in this document are
based on the use of TLS. Therefore, it is strongly RECOMMENDED that based on the use of TLS. Therefore, it is strongly RECOMMENDED that
TLS with non-null encryption is always used. Clients and floor TLS with non-null encryption is always used. Clients and floor
control servers MAY use other security mechanisms as long as they control servers MAY use other security mechanisms as long as they
provide similar security properties (i.e., replay and integrity provide similar security properties (i.e., replay and integrity
protection, confidentiality, and client and server authentication). protection, confidentiality, and client and server authentication).
TLS PSK mode is subject to offline dictionary attacks. In DHE and TLS PSK simply relies on a pre-shared key without specifying the
RSA modes, an attacker who can mount a single man-in-the-middle nature of the key. In practice, such keys have two sources: text
attack on a client/server pair can then mount a dictionary attack on passwords and randomly generated binary keys. When keys are derived
the password. In modes without DHE or RSA, an attacker who can from passwords, TLS PSK mode is subject to offline dictionary
record communications between a client/server pair can mount a attacks. In DHE and RSA modes, an attacker who can mount a single
dictionary attack on the password. Accordingly, it is RECOMMENDED man-in-the-middle attack on a client/server pair can then mount a
that where possible clients use certificate-based server dictionary attack on the password. In modes without DHE or RSA, an
authentication ciphersuites with PSK in order to defend against attacker who can record communications between a client/server pair
dictionary attacks. can mount a dictionary attack on the password. Accordingly, it is
RECOMMENDED that where possible clients use certificate-based server
authentication ciphersuites with password-derived PSKs, in order to
defend against dictionary attacks.
In addition, passwords SHOULD be chosen with enough entropy to In addition, passwords SHOULD be chosen with enough entropy to
provide some protection against dictionary attacks. Because the provide some protection against dictionary attacks. Because the
entropy of text varies dramatically and is generally far less than entropy of text varies dramatically and is generally far less than
that of an equivalent random bitstring, no hard and fast rules about that of an equivalent random bitstring, no hard and fast rules about
password length are possible. However, in general passwords SHOULD password length are possible. However, in general passwords SHOULD
be chosen to be at least 8 characters and selected from a pool be chosen to be at least 8 characters and selected from a pool
containing both upper and lower case, numbers, and special keyboard containing both upper and lower case, numbers, and special keyboard
characters (note that an 8-character ASCII password has a maximum characters (note that an 8-character ASCII password has a maximum
entropy of 56 bits and in general far lower). FIPS PUB 112 [11] entropy of 56 bits and in general far lower). FIPS PUB 112 [PUB112]
provides some guidance on the relevant issues. If possible, provides some guidance on the relevant issues. If possible,
passphrases are preferable to passwords. In addition, a cooperating passphrases are preferable to passwords. In addition, a cooperating
client and server pair MAY choose to derive the TLS PSK shared key client and server pair MAY choose to derive the TLS PSK shared key
from the passphrase via a password-based key derivation function such from the passphrase via a password-based key derivation function such
as PBKDF2 [2]. as PBKDF2 [RFC2898]. Because such key derivation functions may
incorporate iteration functions for key strengthening they provide
some additional protection against dictionary attacks by increasing
the amount of work that the attacker must perform.
When the keys are randomly generated and of sufficient length,
dictionary attacks are not effective because such keys are highly
unlikely to be in the attacker's dictionary. Where possible, keys
SHOULD be generated using a strong random number generator as
specified in [RFC4086]. A minimum key length of 80 bits SHOULD be
used.
The remainder of this Section analyzes some of the threats against The remainder of this Section analyzes some of the threats against
BFCP and how they are addressed. BFCP and how they are addressed.
An attacker may attempt to impersonate a client (a floor participant An attacker may attempt to impersonate a client (a floor participant
or a floor chair) in order to generate forged floor requests or to or a floor chair) in order to generate forged floor requests or to
grant or deny existing floor requests. Client impersonation is grant or deny existing floor requests. Client impersonation is
avoided by using TLS. The floor control server assumes that avoided by using TLS. The floor control server assumes that
attackers cannot hickjack TLS connections from authenticated clients. attackers cannot hickjack TLS connections from authenticated clients.
skipping to change at page 7, line 47 skipping to change at page 8, line 13
client (e.g., why a floor request was denied). TLS confidentiality client (e.g., why a floor request was denied). TLS confidentiality
prevents this attack. Therefore, it is RECOMMENDED that TLS is used prevents this attack. Therefore, it is RECOMMENDED that TLS is used
with a non-null encryption algorithm. with a non-null encryption algorithm.
7. IANA Considerations 7. IANA Considerations
This specification does not contain any actions for the IANA. This specification does not contain any actions for the IANA.
8. Acknowledgments 8. Acknowledgments
Sam Hartman, Karim El Malki, and Vijay Gurbani provided useful Sam Hartman, David Black, Karim El Malki, and Vijay Gurbani provided
comments on this document. Eric Rescorla performed a detailed useful comments on this document. Eric Rescorla performed a detailed
security analysis of this document. security analysis of this document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Kaliski, B., "PKCS #5: Password-Based Cryptography [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
Specification Version 2.0", RFC 2898, September 2000. with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
Session Description Protocol (SDP)", RFC 3264, June 2002. X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[4] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 [RFC3484] Draves, R., "Default Address Selection for Internet
Public Key Infrastructure Certificate and Certificate Protocol version 6 (IPv6)", RFC 3484, February 2003.
Revocation List (CRL) Profile", RFC 3280, April 2002.
[5] Draves, R., "Default Address Selection for Internet Protocol [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
version 6 (IPv6)", RFC 3484, February 2003. Requirements for Security", BCP 106, RFC 4086, June 2005.
[6] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
Transport Layer Security (TLS)", RFC 4279, December 2005. for Transport Layer Security (TLS)", RFC 4279,
December 2005.
[7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[9] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
Protocol (BFCP)", RFC 4582, November 2006. Control Protocol (BFCP)", RFC 4582, November 2006.
[10] Camarillo, G., "Session Description Protocol (SDP) Format for [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format
Binary Floor Control Protocol (BFCP) Streams", RFC 4583, for Binary Floor Control Protocol (BFCP) Streams",
November 2006. RFC 4583, November 2006.
[11] National Institute of Standards and Technology (NIST), [PUB112] National Institute of Standards and Technology (NIST),
"Password Usage", FIPS PUB 112, May 1985. "Password Usage", FIPS PUB 112, May 1985.
9.2. Informative References 9.2. Informative References
[12] Roy, S., "IPv6 Neighbor Discovery On-Link Assumption Considered [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Harmful", draft-ietf-v6ops-onlinkassumption-04 (work in Specification Version 2.0", RFC 2898, September 2000.
progress), January 2006.
[I-D.ietf-v6ops-onlinkassumption]
Roy, S., "IPv6 Neighbor Discovery On-Link Assumption
Considered Harmful", draft-ietf-v6ops-onlinkassumption-04
(work in progress), January 2006.
Author's Address Author's Address
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
 End of changes. 36 change blocks. 
91 lines changed or deleted 111 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/