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

I cleared my DISCUSS.

This document depends on the fingerprint Attribute definition in 
[10], which is draft-ietf-mmusic-comedia-tls-05.  The definition of 
the fingerprint attribute includes:

    hash-func              =  "sha-1" / "sha-224" / "sha-256" /
                              "sha-384" / "sha-512" /
                              "md5" / "md2" / token
                              ; Additional hash functions can only come
                              ; from updates to RFC 3279

RFC 3279 does not define the short strings used here.  RFC 3279 
provides ASN.1 object identifiers, which are not suitable 
here.  draft-ietf-mmusic-comedia-tls needs to say how these 
identifiers will be assigned.  Will IANA maintain a registry?

Russ

At 10:38 PM 12/9/2005, Allison Mankin wrote:
>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
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic