Marcel,
Service level security is required for JSR-82 like Steve pointed it out.
For anyone implementing JSR-82, they would have to add this service level
security themselves. It would be most useful to have it as part of bluez
rather than have people implement their own way of it.
Marcel, if you recall, we've exchanged an email regarding service level security. At that point, you had mentioned thinking about a security manager embedded in bluez that would allow it.
I am currently working on implementing JSR-82 which requires this level
of security. If anyone has already implemented or has a good way of doing it,
please let me know. I would be very interested.
Also, currently there is no service level security in l2cap for outgoing
connections. I would like to know if someone has already taken a stab at it
and if this should be part of bluez in the future.
Regards
Abhi
> 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)
-------------------------------------------------------
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,
> > So the question still stands. Should we already force authentication
> > when the peer sends PN CMD?
>
> Actually p412 in the SPEC (v1.1) says:
>
> "On the responding side, if authentication procedures are triggered from
> RFCOMM, this must only be done when receiving a SABM frame, not when
> receiving configuration commands preparing an unopened DLC (Erratum
> 1052)."
this is a clear statement. Thanks for pointing this out.
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?
> > You must convince me that this is really needed and a good idea. For
> > what kind of application do you wanna use it?
>
> It's for the same reason as stated above: you don't want the connection
> to succeed unless the security requirements can be met. If you have a
> client in security mode 2 and a server in security mode 1, you want the
> server to see an incoming connection _only_ if authentication/encryption
> have been successfully performed. You _don't_ want the server to see an
> incoming connection which is immediately closed.
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.
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
Hi Marcel, Abhi,
On Fri, 2004-10-29 at 15:47, Marcel Holtmann wrote:
> > Service level security is required for JSR-82 like Steve pointed it out.
> > For anyone implementing JSR-82, they would have to add this service level
> > security themselves. It would be most useful to have it as part of bluez
> > rather than have people implement their own way of it.
>
> actually you can't implement it in a sane way in userspace, because you
> don't have control over the RFCOMM signalling channel.
Marcel is right here. You can try and kludge it by trying to enforce the
security requirements _after_ the connection has been accepted but this
is pretty horrible (and it's hard to prevent acceptAndOpen() returning a
connection which is immediately closed).
> > Marcel, if you recall, we've exchanged an email regarding service level security. At that point, you had mentioned thinking about a security manager embedded in bluez that would allow it.
>
> This is a little bit different, because this is more basic stuff. You
> need to integrate the trigger points of the Bluetooth security mechanism
> into the RFCOMM layer. And actually the state machine of RFCOMM is more
> complex than the one of L2CAP. For me it is not clear at the moment what
> is the best thing to do without breaking anything.
>
> So the question still stands. Should we already force authentication
> when the peer sends PN CMD?
Actually p412 in the SPEC (v1.1) says:
"On the responding side, if authentication procedures are triggered from
RFCOMM, this must only be done when receiving a SABM frame, not when
receiving configuration commands preparing an unopened DLC (Erratum
1052)."
> > I am currently working on implementing JSR-82 which requires this level
> > of security. If anyone has already implemented or has a good way of doing it,
> > please let me know. I would be very interested.
>
> As mentioned above the only way is inside the kernel, because otherwise
> you will trigger after the MSC exchange and this is too late.
>
> > Also, currently there is no service level security in l2cap for outgoing
> > connections. I would like to know if someone has already taken a stab at it
> > and if this should be part of bluez in the future.
I've had a look at this recently. If I get time I will have a go at
implementing it.
> You must convince me that this is really needed and a good idea. For
> what kind of application do you wanna use it?
It's for the same reason as stated above: you don't want the connection
to succeed unless the security requirements can be met. If you have a
client in security mode 2 and a server in security mode 1, you want the
server to see an incoming connection _only_ if authentication/encryption
have been successfully performed. You _don't_ want the server to see an
incoming connection which is immediately closed.
Regards,
Steve
--
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
[email protected] +353-1-6601315 (ext 209)
Hi Abhi,
> Service level security is required for JSR-82 like Steve pointed it out.
> For anyone implementing JSR-82, they would have to add this service level
> security themselves. It would be most useful to have it as part of bluez
> rather than have people implement their own way of it.
actually you can't implement it in a sane way in userspace, because you
don't have control over the RFCOMM signalling channel.
> Marcel, if you recall, we've exchanged an email regarding service level security. At that point, you had mentioned thinking about a security manager embedded in bluez that would allow it.
This is a little bit different, because this is more basic stuff. You
need to integrate the trigger points of the Bluetooth security mechanism
into the RFCOMM layer. And actually the state machine of RFCOMM is more
complex than the one of L2CAP. For me it is not clear at the moment what
is the best thing to do without breaking anything.
So the question still stands. Should we already force authentication
when the peer sends PN CMD?
> I am currently working on implementing JSR-82 which requires this level
> of security. If anyone has already implemented or has a good way of doing it,
> please let me know. I would be very interested.
As mentioned above the only way is inside the kernel, because otherwise
you will trigger after the MSC exchange and this is too late.
> Also, currently there is no service level security in l2cap for outgoing
> connections. I would like to know if someone has already taken a stab at it
> and if this should be part of bluez in the future.
You must convince me that this is really needed and a good idea. For
what kind of application do you wanna use 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 Marcel,
On Fri, 2004-10-29 at 17:40, Marcel Holtmann wrote:
> 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.
> 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.
> Regards
>
> Marcel
Steve
--
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
[email protected] +353-1-6601315 (ext 209)