The RMT building blocks to standards track and security

Hi RMTers,

I, as your AD would like to start a discussion regarding security 
building blocks and ensuring that them are in place and used in protocol 
instantiations.

I don't know how many of you are aware of BCP 61: Strong Security 
Requirements for Internet Engineering Task Force Standard Protocols.

This BCP contains the following statement:

    The solution is that we MUST implement strong security in all
    protocols to provide for the all too frequent day when the protocol
    comes into widespread use in the global Internet.

Which in practice as I understand it must mandate implementation (not 
usage) of security solutions for the security issues that are present in 
our standard track protocols. In the case of RMT it seems that this 
mandate falls onto the PIs.

The reason I am raising this now is that we are working on moving most 
building blocks and our PIs to proposed standard. I think the security 
consideration sections of the different building blocks are in decent 
shape. However what is lacking is the mandate on solutions. They are 
currently pointing on possible solutions and are not providing the 
details necessary for interoperable implementations. In some cases I 
also thing the security solutions are still not ready.

Due to that being the current status ,I would like the WG to have a 
discussion about this topic on the list and in Montreal. I think the 
important topics are:

1. Have we correctly characterized the security issues related to the 
different BBs and PIs? Do we understand the different usage scenarios 
and the resulting cases?

2. What security protocol requirements does 1 result in.

3. Does the solutions exist or are under development to fulfill the 
requirements in 2? Do we need to improve our dialog with groups like MSEC?

4. Ensure that we get sufficient security area interest in our 
specifications to help ensure that we correctly describe how to use the 
protocols in the PIs.


I would like to have this discussion producing some results quite 
quickly so that we don't loose to much time, and avoid having the 
security area produce solutions that are not suitable for us.

I will start another email thread on what I consider to be the primary 
cases and issues. However, this will require some of your energy to make 
it work.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email protected]