Subject: [MMUSIC] Progressing/Resolving the IESG Review of the BFCP specs

From: Allison Mankin <[email-masked]>
Date: Fri, 09 Dec 2005 19:38:41 -0800

Russ, Sam, Ted -

Gonzalo has worked with you all, and spoke to the respective
working groups.  He has published revisions of the two specs
which we believe should resolve your Discusses.  Below are his
comments on how.  I've added a bit of commentary inline at a few
places [AJM: ]

Please let us know if you are able to clear now.

Allison

------ Gonzalo writes ---

I have put together new revisions of the BFCP drafts. They should
address all the discusses in the ID tracker.

http://www.ietf.org/internet-drafts/draft-ietf-xcon-bfcp-06.txt
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bfcp-03.txt

Below I provide detailed answers to all the discusses:

MMUSIC document:
https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1786&filename=draft-ietf-mmusic-sdp-bfcp

> Bill Fenner:
> 
> Discuss [2005-09-01]: Port 20000 belongs to a protocol named 'DNP';
> should this example be from the dynamic port range (49152-65535) or
> should bfcp have an IANA-assigned port number?

The draft now uses ports in the dynamic port range.

[AJM: Bill has cleared his Discuss]

> Sam Hartman:
> 
> Discuss [2005-08-31]: 1) Please replace the RFc 1750 reference with
> RFC 4086.

I have removed this reference as a result of removing the digest mechanism.

> 
> 2) RFC 3548 is an informational RFC but is referenced as a normative 
> reference; RFC 3967 requires that this fact be mentioned in the last 
> call.  It was not. This document needs to be last called again or 
> that reference changed.  [Yes, I think this requirement is wrong; I 
> also understand the argument that we should follow our rules 
> consistently]

I have removed this reference as a result of removing the digest mechanism.

  3) I'm uncomfortable with this document being approved
> before draft-ietf-mmusic-media-tls.  Based on how this protocol
> works, I suspect I have comments on that draft and depending on how
> those comments are resolved, I think this draft may change.  In 
> particular, I'm concerned about cases where the active open side of 
> the connection is the TLS server, the handling of the fingerprint 
> attribute and some concerns about asymmetry in this protocol.

[AJM: Sam, draft-ietf-mmusic-media-tls is in IETF Last Call now -
      I am shepherding it.  There will be no change initiated by the 
      working group.  We really need your comments on the draft -
      I solicited this from you again in a pre-IETF Last Call heads
      up.  There's some time pressure because of outside bodies
      calling these protocols critical dependencies...]

This draft normatively depends on the SDP TLS draft. So, in any case, it
will need to wait for it before it can be published as an RFC.

> 
> 4) This document is not aligned with the main BFCP document.  First, 
> if the server can do active opens then section 6 and 14 of the BFCP 
> document need to discuss that.  If the authors of this document 
> confirm that this document's behavior is correct, then I can amend my
> BFCP discuss.

I have clarified in the main BFCP spec that the floor control server can
do active opens.

> 5) The authentication handling in this document is not aligned with 
> BFCP.  Section 8.1 of this document implies that digest is not used 
> if TLS is used; as discussed by section 9.2 of the BFCP document, 
> BFCP seems to support modes where both TLS and digest are used. 
> Similarly, section 8.2.1 only allows the digest shared secret to be 
> negotiated for tcp/bfcp not tcp/tls/bfcp.  Again, I'm happy if these
>  document are aligned in either direction.

I have removed the digest mechanism from the drafts. Now TLS is mandated.

> 6)  IT seems like the attributes discussed in section 8.1 need to be 
> integrity protected.  However the security considerations does not 
> discuss this issue.

I have removed the digest mechanism from the drafts. Now TLS is mandated.

> Comment [2005-08-31]: I'm not sure I see a way that a server can
> offer both a TLS and non-TLS stream using this media type.  If
> clients end up being required to support TLS tihs probably doesn't
> matter.  However it may be an issue if clients are not required to
> support TLS.  Perhaps I'm missing some information about how
> offer/answer works.  It definitely seems that two m lines would be
> wrong because then a client could accept both of them.

Now TLS is mandated.

> 
> Russ Housley:
> 
> Discuss [2005-09-01]:
> 
> The value "c2hhcmVkLXNlY3JldA==" is used throughout the document as
> the shared secret example value.  While the ASCII string that was 
> encoded to make this value is cute, the string is not long enough. 
> RFC 2104 recommends that the key for HMAC-SHA-1 be 20 octets.

I have removed the digest mechanism from the drafts. Now TLS is mandated.

> I find the structure of section 8 very confusing.  The authentication
>  of the SIP session that is used to perform an offer/answer exchange 
> is not clearly separated from the authentication of the BFCP protocol
>  entities.  Further, if the 'fingerprint' attribute is not present, 
> what checks must be performed to ensure that the non-self-signed 
> certificate used for offer/answer exchange authentication belongs to 
> to the same party as the non-self-signed certificate used with 
> BFCP/TLS/TCP.  This (and perhaps other related topics) belong in a 
> subsection that does not currently exist.

With the removal of the digest mechanism everything should be clearer.

> Section 8 says:
>> 
>> Note that when mutual authentication is performed using TLS, it is 
>> not necessary to use this digest mechanism.
>> 
> This does not agree with draft-ietf-xcon-bfcp-05, which says that the
>  digest mechanism must be used for the first message, even when TLS
> is employed.
> 
> Section 8.1 says:
>> 
>> ... the certificate provided at the TLS-level must be signed by a 
>> certificate authority known to other party.
>> 
> This is not quite correct, and the terminology does not align with 
> RFC 3280.  I suggest:
>> 
>> ... the certificate provided at 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 terminates at one of the
>> other party's trust anchors.
>> 

I have modifies the text according to your suggestion.

> Also, a normative reference to RFC 3280 in this section is desirable.
> 

Added.

> 
> Section 8.2.1 says:
>> 
>> The key-params field SHOULD use the 'inline' key method followed by
>>  a base64-encoded [6] unguessable secret [1].
>> 
> Please state the size of the shared secret value.  I suspect that the
>  size depends on the selected integrity check function.

The digest mechanism has been removed from the draft.

> 
> Bert Wijnen:
> 
> Comment [2005-09-01]:
> 
> This document has a normative reference: [9]   Levin, O. and G.
> Camarillo, "The SDP (Session Description Protocol) Label Attribute", 
> draft-levin-mmmusic-sdp-media-label-00 (work in progress), July 2004.
> 
> 
> and that document is an individual Internet-Draft, that also has
> expired. So what impact does this have?

I have updated the reference to draft-ietf-mmusic-sdp-media-label, which
is a WG item.

[AJM: and it is in the RFC Editor Queue]

XCON document:
https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1785&filename=draft-ietf-xcon-bfcp

> Brian Carpenter:
> 
> Comment [2005-09-01]:
> 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 ...

The requirements document has already been approved and is in the RFC
Editor's queue at this point.

> 
> Ted Hardie:
> 
> Discuss [2005-08-31]:
> The document says that it fulfills the requirements of
> draft-ietf-xcon-floor-control-req, but the draft
> has apparently expired.  

The requirements document has already been approved and is in the RFC
Editor's queue at this point.

> 
> 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.

I have clarified the scope of this attribute.

> 
> Sam Hartman:
> 
> Discuss [2005-08-31]:
> 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.

All the attributes are32-bit aligned. Therefore, it is always possible
to find the next attribute.

> 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?

The digest mechanism has been removed.

> 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.

The digest mechanism has been removed.

> 
> 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.

Now TLS is mandatory for all BFCP nodes (both servers and clients).

> 
> 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?

TLS now is mandatory. I have also added text saying that nodes should
check that messages coming over a given TLS connection use a valid User
ID to avoid attacks.

> 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?  

Now digest has been removed and TLS with self-signed certificates is the
  mechanism to use.

> 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.

Now TLS is mandatory and digest has been removed.

> 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.

Digest has been removed.

> 
> 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.

Digest has been removed.

> 
> 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.

Now TLS is mandatory and digest has been removed.

> 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.

Digest has been removed.

> 
> 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.

Now TLS is mandatory.

> 
> Scott Hollenbeck:
> 
> Comment [2005-08-29]:
> 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.

Done.

> Russ Housley:
> 
> Comment [2005-08-31]:
> 
>   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.

As a result of my discussions with Sam, I have removed the digest
mechanism from the document.

> 
> Bert Wijnen:
> 
> Comment [2005-09-01]:
> 
> 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.
> 

Changed to normative.

Thanks,

Gonzalo

------- End of Forwarded Message

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Ted Hardie <[email-masked]>
Date: Mon, 12 Dec 2005 10:55:19 -0800

I've cleared my DISCUSS.  Thanks for the updates on USER-URI; the new text is
much clearer, and I think it will help implementors get the right thing done here.
			regards,
				Ted

---

From: Sam Hartman <[email-masked]>
Date: Fri, 16 Dec 2005 15:28:09 -0500

I'm clearing all my discusses on the BFCP documents.

Thanks for the great work.