Re: Service level security for RFCOMM

Hi Steve,

> > actually it seems that nobody really cares about service level security
> > on the RFCOMM layer. Or people are too lazy to send in a patch. However,
> > I spent some hours with thinking about it and the core stuff of a small
> > framework for providing authentication and encrypt feedback from HCI to
> > higher level protocols is finished.
> 
> Perhaps this is because no-one except you and Max understands the RFComm
> state-machine? :-)

this maybe right, but it is a problem of the RFCOMM protocol itself and
the differences between the 1.0b and 1.1 specification :(

> > The problem now is to change the RFCOMM state machine to deal with it
> > and reject connections in the failure case. After looking at the state
> > machine of RFCOMM, I realized that there are two posibilities when to
> > trigger the authentication. One is after we receive the PN CMD and the
> > other after the SABM for the specific channel. The specification says
> > nothing about that. What are the pros and cons?
> > 
> > And btw, who is really interested in this feature or needs it?
> 
> This is useful (and probably required, I can't remember) for JSR-82.
> Especially for people who want to encrypted/authenticated OBEX
> connections.

And what to do next? When should the authentication be triggered? What
should happen if the encryption on a link gets deactivated afterwards?

> Are you going to do the client-side too?

I have no plan for this, because I don't see the need. What is bad in
using security mode 1 for outgoing and security mode 2 for incoming?

Regards

Marcel




-------------------------------------------------------
This Newsletter Sponsored by: Macrovision 
For reliable Linux application installations, use the industry's leading
setup authoring tool, InstallShield X. Learn more and evaluate 
today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/