The Binary Floor Control Protocol (BFCP)
draft-ietf-xcon-bfcp-06

[Ballot comment]
Comment from John Loughney

Intro says:

  The Requirements for Floor Control Protocol [10] list a set of
  requirements that need to be met by floor control protocols.  The
  Binary Floor Control Protocol (BFCP), which is specified in this
  document, meets these requirements.

-> "Requirements for Floor Control Protocol" seems to have expired.
  Awfully hard to know if the requirements have been met by this
  protocol, if they've expired ...

IANA Last Call Comments:
Upon approval of this document the IANA will create a new registry for Binary Floor Control Protocol (BFCP) Parameters.  There will be 5 sub-registries pre-populated with the registrations in this document.

[Note]: 'Last Call will end 9/2.  The companion mmusic document
got its Last Call ending 9/1 and this one slipped over to the next day.   If IETF wide issues arise, it is possible to remove
the document from the closely following IESG consideration.  IETF Last Call review is encouraged!' added by Michelle Cotton

[Ballot comment]
I think that this informative reference:
  [13]  Camarillo, G., "Session Description Protocol (SDP) Format for
        Binary Floor Control Protocol  (BFCP) Streams",
        draft-ietf-mmusic-sdp-bfcp-01 (work in progress), May 2005.

Should really be a normative reference. As far as I can tell, you better
understand the content of that mmusic-sdb-bfcp if you want to implement
this xcon-bfcp specification.

[Ballot comment]
Comment from John Loghney

Intro says:

  The Requirements for Floor Control Protocol [10] list a set of
  requirements that need to be met by floor control protocols.  The
  Binary Floor Control Protocol (BFCP), which is specified in this
  document, meets these requirements.

-> "Requirements for Floor Control Protocol" seems to have expired.
  Awfully hard to know if the requirements have been met by this
  protocol, if they've expired ...

[Ballot discuss]
The document says that it fulfills the requirements of draft-ietf-xcon-floor-control-req, but the draft
has apparently expired. 

The document describes the USER-URI field by saying:

  Text: this field contains the UTF-8 encoded URI of the user.

Further details on what is meant by this seem required to get interoperable use.  The document
does note that it is returned in responses to User Query messages, but it is not clear if it is
limited to a contact uri or has a broader applicability.

[Ballot comment]
Sam Hartman and I had a long discussion about this document, and
  we decided that it would be best if only one DISCUSS ballot position
  is posted by a Security Area Director.  As a result, Sam is posting
  a DISCUSS position, and I am posting a NO-OBJECTION position.  The
  position posted by Sam is a union of our concerns, and the authors
  only need to work with one Security Area Director to resolve the
  concerns that are being raised.

[Ballot discuss]
Section 5.2 says:
> Length: this 8-bit field contains the length of the attribute in
> bytes, excluding any padding defined for specific attributes.
If I understand this text correctly, it means that a new attribute
can be defined with padding requirements such that the length byte
is not enough to find the end of this attribute and the beginning
of the next attribute because the padding is not included in the
length.  This seems against the goal of having extensible attributes.

Section 5.2.7 indicates that the length of the DIGEST attribute
payload is always 24 bytes.  This seems to be composed of:
        header = 2 bytes
        algorithm = 1 byte
        digest = 20 bytes (for HMAC-SHA-1)
        padding = 2 bytes
This adds up to 25 bytes.  Please correct.  Also, the size of
this attribute should not be constant.  How would HMAC-SHA-256
be supported?

Section 5.2.7 says:
> When HMAC-SHA1 is used, the input text needs to be padded so as
> to be a multiple of 64 bytes.
Why?  HMAC-SHA-1 can be used to authenticate messages of arbitrary
size.

Section 7 makes TLS mandatory for servers but not for clients.
The authors need to consider the requirements of RFC 4107. I believe
this specification requires automated key management; if there is a
convincing argument why manual key management is appropriate, it needs
to be stated clearly, probably deserving a subsection in the security
considerations. I think the easiest fix is to require clients to
implement TLS so that there is mandatory automated key management.

In sections 6 and 7, how does a client know whether a particular
connection is using TLS?  How about a server?  Are separate ports
required?

There is a conflict between section 9.1 and 9.2. Section 9.1 assumes
that both parties in the TLS exchange have certificates. However
section 9.2 assumes that the client is not authenticated and is using
the digest attribute for authentication. Please resolve this
conflict. I think the conflict also spills over into the text in
section 14. Presumably the desire is to support clients without
certificates; make it clear in section 9.1 that this is permitted and
make it clear in sections 9.2 and 14 that there are three modes to
consider: TLS with all parties having certificates, TLS with the
server having a certificate but the client not having a certificate,
and no TLS protection at all. Also, what happens if a client has a
certificate that the server is unwilling accept? Does it use the
digest attribute? If so, how does it know it should use the digest
attribute instead of depending on TLS level authentication? 

The assumption in section 9.2 seems to be that servers are
authenticated to clients via TLS, but this is only true if the client
can validate the certificate. In the absence of TLS protection, the
client's DIGEST-protected message can be replayed by a man-in-the-
middle to a real server. If the DIGEST attribute is only required
for the first message, then the man-in-the-middle can inject future
messages. The document needs to specify under what circumstances
clients verify certificates, and several details on certificate
verification need to be described. What subject names are expected
in the server's certificate? Must the client always have fingerprints
of certificates through mechanisms similar to [13]? If certificates
are ever accepted without verification, then the vulnerability to
man-in-the-middle with only the first message containing DIGEST
attributes needs to be discussed in the security considerations
section.

Section 9.2 needs to be strengthened. It needs to require that the
DIGEST attribute be the last attribute in the message. I want to
confirm that clients only use the NONCE once and that they must wait
for a server response to see if the NONCE attribute is included in
order to know whether to include a NONCE attribute in the next
message. Is 16-bits really larger enough for a nonce?  Given the
requirement that "and a NONCE attribute with a nonce value that is
unguessable by attackers," 2**16 possible values seems too few.
Further, please reference RFC 4086 regarding nonce value generation.
Why does the nonce need to be unguessable anyway?  It seems like
requiring nonces never be reused with a given shared secret is
sufficient.

Section 9.2, I believe there are problems if an unauthenticated
server can tell a client what nonce value to use. The most serious
problem involves a server that supports TLS and a client that does
not require TLS. An attacker can trick the client into not using
TLS. The attacker sends a message to the server without a NONCE
attribute or DIGEST attribute, sees what nonce value the server
wants, and then generates an error reply to the real client
requesting this nonce value. The client responds with some message
including the NONCE and DIGEST attributes. The attacker then
sends this message to the server. Since the attacker is using TLS
to communicate to the server and since the server only requires
the first message to be authenticated, the attacker may now send any
message authenticated as the client. This attack must be thwarted,
possibly by defining an attribute indicating that a particular
message (is|is not) being sent over a TLS channel. Any remaining
attacks based on the fact that the error containing the nonce
value is not authenticated must be documented.

Section 9.2 chooses not to authenticate messages from the server to
the client. I don't like this design decision and would recommend
that the working group change its mind. However I cannot require this
change. I do require that this decision be clearly documented.  This
is especially problematic when the nonce value is sent to the client.
Without the DIGEST attribute on this message, the client has no way
to determine that the nonce value is actually coming from the server.

Section 9.2 assumes that the shared secret can be used with any digest
algorithm. I don't think it is guaranteed that all keys are valid
with all algorithms.  For example, HMAC-SHA-1 has a minimum requirement
on the key size.

The security considerations section seems to gloss over many attacks
and simply recommend using TLS. Please do separate security analysis
for the protocol when TLS is used and the protocol when just the
digest attribute is used. Once that is done, I'd like to re-review.

[Ballot comment]
Sam Hartman and I had a long discussion about this document, and
  we decided that it would be best if only one DISCUSS ballot position
  is posted by a Security Area Director.  As a result, Sam is posting
  a DISCUSS position, and I am posting a NO-OBJECTION position.  The
  position posted by Sam is a union of our concerns, and the authors
  only need to work with one Security Area Director to resolve the
  concerns that are being raised.

[Ballot discuss]
Section 5.2 says:
>  Length: this 8-bit field contains the length of the attribute in
>  bytes, excluding any padding defined for specific attributes.  The
If I understand this text correctly, it means that a  new attribute can be defined with padding requirements such that the length byte
is not enough to find the end of this attribute and the beginning of the next attribute because the padding is not included in the length.
This seems against the goal of having extensible attributes.

Section 7 makes TLS mandatory for servers but not for clients.
The authors need to consider the requirements of RFC 4107.  I believe
this specification requires automated key management; if there is a
convincing argument why manual key management is appropriate, it needs
to be stated clearly.    I think the easiest fix is to require clients
to implement TLS  so that there is mandatory automated key
management. 

There is a conflict between section 9.1 and 9.2.  Section 9.1 assumes
that both parties in the TLS exchange have certificates.  However
section 9.2 assumes that the client is not authenticated and is using
the digest attribute for authentication.  Please resolve this
conflict; I think it also spills over into the text in section 14.
Presumably the desire is to support clients without certificates; make
it clear in section 9.1 that this is permitted and make it clear in
section 14 and 9.2 that there are three modes to consider: TLS with
all parties having certs, TLS with no client cert , no TLS.  Also,
what happens if a client has a cert that the server does not like?
Does it use the digest attribute?  If so, how does it know it should
use the digest attribute?

The assumption in section 9.2 that servers are authenticated to
clients via TLS is only true if the client can verify the certificate.
In particular if a client does not verify the server and does not have
a certificate of its own, then its digest message can be replayed by a
man in the middle to a real server.  If the digest attribute is only
required for the first message, then the man in the middle can inject
future messages.  As such, the document needs to discuss under what
circumstances clients verify certificates and what certificate
verification is to be used.  What names are expected or must the
client always have fingerprints of certificates through mechanisms
similar to [13]?  If certificates are ever accepted without
verification, then the vulnerability to man-in-the-middle with only
the first message containing digest attributes needs to be discussed
in the security considerations section.

Section 9.2 needs to be strengthened.  It needs to require that the
digest attribute be the last attribute in any message containing the
digest attribute.  I want to confirm that clients only use nonces
once and that they must wait for a server response  to see if the
nonce attribute is included in order to know whether to include a
nonce in the next message.  Is 16-bits really enough size for a nonce?
In particular, will there ever be more than 2**16 messages using the
same shared secret?

Still in section 9.2, I believe there are problems if an
unauthenticated server can tell a client what nonce to use.  The most
serious problem involves a server that supports TLS and a client that
does not require TLS.  An attacker can trick the client into not using
TLS.  The attacker sends a message to the server without a nonce or
digest, sees what nonce the server wants, and then generates an error
reply to the real client requesting this nonce.  The client responds
with some message including a nonce and digest.  The attacker then
sends this message to the server.  Since the attacker is using TLS to
communicate to the server and since the server  only requires the
first message to be authenticated, the attacker may now send any
message authenticated as the client.  This attack must be solved,
possibly by defining an attribute indicating that a message (is|is
not) sent over a TLS channel.  Any remaining attacks based on the fact
that the error containing the nonce  is not authenticated  must be
documented.

Section 9.2 chooses not to authenticate messages from the server to
the client.  I don't like this design decision and would recommend
that the working group change its mind.  However I cannot require this
change.  I do require that this decision be clearly documented.

Section 9.2 assumes that the shared secret can be used with any digest
algorithm.  I don't think it is guaranteed that all keys are valid
with all algorithms.

The security considerations section seems to gloss over many attacks
and simply recommend using TLS.  Please do separate security analysis
for the protocol when TLS is used and the protocol when just the
digest attribute is used.  Once that  is done, I'd like to re-review
the security considerations section.

[Ballot comment]
The document uses the word "byte" in many places to describe things like pad values.  While I'll agree that a byte contains 8 bits on most modern computers, it's generally better to use "octet" if 8-bit values are being described.

[Ballot discuss]
I'll hold this Discuss just because the IESG agenda is 9/1 and the Last Call closure is 9/2.
I timed the request for LC a bit tightly and the mmusic doc made it but not this one.

[Note]: 'Last Call will end 9/2.  The companion mmusic document
got its Last Call ending 9/1 and this one slipped over to the next day.  
If IETF wide issues arise, it is possible to remove
the document from the closely following IESG consideration.  IETF Last Call review is encouraged!' added by Allison Mankin

[Note]: 'Last Call will end 9/2.  I will hold Discuss for the one day.  The companion document
got its Last Call ending 9/1 and this one slipped over to the next day.  In both cases if
there are issues that require WG review or recycling, the agenda items will be withdrawn -
Last Call is very much encouraged!' added by Allison Mankin