[BEEPwg] Trouble with TLS and transport mappings

Jered Floyd jered@permabit.com
27 Nov 2001 11:32:39 -0500


> this would work, although you probably meant to say "must" instead
> of "may".

Great; works for me.  What's the next step?  Do we just note this and
remember it for when a specification revision occurs?


Something I mentioned 2 messages ago but didn't see an opinion on:
Once transport layer security of any kind has been negotiated, may a
different tls negotiation occur? Section 4.1 makes it clear that the
BEEP SASL profile (as opposed to the SASL BEEP profiles, argh)
explicitly does not permit multiple successful SASL negotiations.
Other (non-SASL) tls negotations are outside the scope of this,
though.

It would be consistent with the choice made in Section 4.1 to add
after the fist paragraph of section 3 the following:

  "Only one successful transport security negotiation may occur
   in a protocol session."

Would you be amenable to this?


The other option would be to explicitly allow multiple tls
negotations.  To be consistent with RFC 2222 (SASL) Section 5.3, only
one security layer may be in effect; if a subsequent negotiation
selects a second security layer, then the second security layer
replaces the first.  If this is preferred, then Section 4.1 of RFC
3080 should be changed to explicitly allow multiple SASL negotiations.

I can think of no reason to support this beyond paranoia; i.e. wishing
to obscure a high-security tls negotiation within a weakly-secured
connection.


Finally, while we're squashing issues, I'll bring up two options for
resolving my previous concern regarding the character set of base64
encoded initialization messages.

1) If backwards-compatibility is not a concern:

Errata against RFC 3080: the 'encoding' attribute is depricated.
Initialization messages as described in Section 2.3.1.2 are precisely
BEEP Messages, as defined in Section 2.2. A
"Content-Transfer-Encoding" may be specified to protect content.

Additionally, the default "Content-Type" could be
"application/beep+xml", which would maintain compatibility with
existing beep+xml profiles (such as TLS and SASL profiles). (This
would only add an additional newline to the head of the initialization
message.)


2) If backwards compatibility is a concern:

The 'base64' value for the 'encoding' attribute should not be used.
The 'encoding' attribute may take the value 'msg', in which case the
content is interpreted as a BEEP Message, as described in option 1
above.  Support for this is indicated via a feature in the greeting.


Which is the better solution?

--Jered