Hi Folks,
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.
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?
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/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fred,
> > > And btw, who is really interested in this feature or needs it?
>
> Over here! I'm interested.
ok, so lets count. The KDE Bluetooth framework will be the first user :)
> I would like to integrate service level security into the meta server of
> kdebluetooth. At the moment you can allow/disallow connections (or show a
> confirmation popup) based on the service/rfcomm channel and on the peer
> device address, but we can't ask for an authenticated link. Being able to use
> service level security would allow us to force authenticated links when using
> any service other than obex push, which should work without having to pair
> devices first.
> IIRC I asked you to allow every user to send authentication requests a few
> months ago, so that even programs running without root privileges can trigger
> authentication. But then I didn't post it on the list as you told me, to let
> other people comment on the security implications. The corresonding patch
> changed only a single bit somewhere, but of course this solution is not very
> conveniant. But if you want authentication to appear as a property of a
> single rfcomm connection that's fine too, as long as a regular users are
> allowed to use this feature. Would that be safe?
You should always remember that the authentication is per device and not
per service. You can trigger it on a per service basis, but it is still
common for the complete device.
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/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Friday 29 October 2004 11:31, Stephen Crane wrote:
> On Fri, 2004-10-29 at 05:42, Marcel Holtmann wrote:
> > 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.
..
> > And btw, who is really interested in this feature or needs it?
Over here! I'm interested.
I would like to integrate service level security into the meta server of
kdebluetooth. At the moment you can allow/disallow connections (or show a
confirmation popup) based on the service/rfcomm channel and on the peer
device address, but we can't ask for an authenticated link. Being able to use
service level security would allow us to force authenticated links when using
any service other than obex push, which should work without having to pair
devices first.
IIRC I asked you to allow every user to send authentication requests a few
months ago, so that even programs running without root privileges can trigger
authentication. But then I didn't post it on the list as you told me, to let
other people comment on the security implications. The corresonding patch
changed only a single bit somewhere, but of course this solution is not very
conveniant. But if you want authentication to appear as a property of a
single rfcomm connection that's fine too, as long as a regular users are
allowed to use this feature. Would that be safe?
regards
Fred
--
Fred Schaettgen
[email protected]
-------------------------------------------------------
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/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Fri, 2004-10-29 at 05:42, Marcel Holtmann wrote:
> 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? :-)
> 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.
Are you going to do the client-side too?
Steve
--
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
[email protected] +353-1-6601315 (ext 209)
Hi James,
> I'm afraid I don't understand the issues enough to know if I need the
> feature.
at the moment you can trigger authentication and encryption for server
sockets on a per PSM basis for the L2CAP. If you use RFCOMM you can't
trigger this and especially not per RFCOMM channel.
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/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
I'm afraid I don't understand the issues enough to know if I need the
feature.
--
James Cameron http://quozl.netrek.org/
HP Open Source, Volunteer http://opensource.hp.com/
PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/
-------------------------------------------------------
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/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Steve,
> > However this also leads to a security problem, because I can scan the
> > RFCOMM ports of a remote device without forcing the security mechanism.
> > I only have to do the PN exchange and then disconnect. What should a
> > remote device do when a PN CMD comes in for a channel without a service
> > behind it?
>
> If the spec says that authentication can only happen on receipt of SABM,
> then I guess this leaves it open to port scans.
>
> However, does this really matter? If you want to protect _all_ services,
> use security mode 3. If you're in security mode 2, it's most likely that
> you can do SDP searches without performing a security procedure and
> discover open channels that way.
yes, it matters, because security mode 3 is never the answer to any
security related problems. You still need a very good policy engine
behind the security manager to protect your device. I would advice
anybody not to use security mode 3, even if the device supports only a
single service. A single trust model is not working.
> > Sorry, I don't get the point. Why should a client care about security
> > mode 2, when it want to connect to a server in security mode 1. Actually
> > the server must know what services to protect and not the client. If you
> > have such server running, then this is a wrong designed server from my
> > point of view.
>
> Well, for example, a client may wish to authenticate a server before
> connecting to it, irrespective of the security the service wants for
> itself.
I still don't see the full need behind this, but send in a clean patch
for it and I will apply it. There should be no problem to support it.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel