public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
* RE: [Bluez-devel] Service level security for RFCOMM
@ 2004-10-29 20:04 Bhatt Abhi-ABHATT
  2004-10-29 20:22 ` Marcel Holtmann
  0 siblings, 1 reply; 20+ messages in thread
From: Bhatt Abhi-ABHATT @ 2004-10-29 20:04 UTC (permalink / raw)
  To: 'Marcel Holtmann'; +Cc: BlueZ Mailing List

Marcel,

> And btw I got the service level security for incoming RFCOMM channels
> working on my development system and I did it without modifying the
> current state machine and it is hopefully SMP safe. I think we need
> another timer on the server side that kills the connection if nobody
> wants to authenticate, but thats another thing to look at. So someone
> owes me a crate full of beer :)
That is great news!! When do i get to see the code:) I don't know 
where you live or else you would have a crate full of beer delivered to you
right about now:) Thanks a bunch.	

Regards
Abhi

Hi Abhi,

don't forget to use the "Reply to All" button ;)

> > it is the same. I already committed the needed stuff to the CVS and
> > changed rctest to set them. However without a correct kernel the call of
> > setsockopt() will fail.
> I am not clear on what this means. Could you please explain what it is that
> you've added and committed in to CVS ?

I like to say look at my latest changes in the CVS and look at rctest,
but it seems that the anonymous CVS is not in sync with the developer
CVS. Again, this is a Sourceforge problem and I heard of other projects
that had the same problems at the moment.

However, I added RFCOMM_LM and RFCOMM_LM_AUTH resp. RFCOMM_LM_ENCRYPT
with the same values as we used for their L2CAP_* counterparts. So you
can use the setsockopt() with these values to achieve the same effect as
you expect on L2CAP. But without a kernel that knows about RFCOMM_LM the
setsockopt() and getsockopt() calls will fail.

And btw I got the service level security for incoming RFCOMM channels
working on my development system and I did it without modifying the
current state machine and it is hopefully SMP safe. I think we need
another timer on the server side that kills the connection if nobody
wants to authenticate, but thats another thing to look at. So someone
owes me a crate full of beer :)

Regards

Marcel

^ permalink raw reply	[flat|nested] 20+ messages in thread
[parent not found: <5987A7CB1694D811A04D0002B32C289601BF3C03@il93exb05.corp.mot.com>]
* RE: [Bluez-devel] Service level security for RFCOMM
@ 2004-10-29 15:35 Bhatt Abhi-ABHATT
  2004-10-29 15:53 ` Stephen Crane
  2004-10-29 17:02 ` Marcel Holtmann
  0 siblings, 2 replies; 20+ messages in thread
From: Bhatt Abhi-ABHATT @ 2004-10-29 15:35 UTC (permalink / raw)
  To: 'Stephen Crane', Marcel Holtmann; +Cc: BlueZ Mailing List

Hi Steve, 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. 
> 
> 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).

Sorry for the confusion but I wasn't referring to user space at all. I was thinking of having the rfcomm service level security implemented in almost the same way as the l2cap service level security(incoming connection). The service level security options could be set using setsockopt(..) in rfcomm. This in turn could be used to set the service level settings for the l2cap socket it uses. I can draw a sequence diagram(function calls) to show how i
picture the design. I'll do that.

> > 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.

Steve, I would be interested to know how you intend to implement it.


> You must convince me that this is really needed and a good idea. For 
> what kind of application do you want to 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.	

Plus JSR-82 requires that service level security should be possible for
outgoing connections. So for anyone trying to implement JSR-82 and using
bluez, it is needed.

Regards
Abhi


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
steve.crane@rococosoft.com +353-1-6601315 (ext 209)

^ permalink raw reply	[flat|nested] 20+ messages in thread
* RE: [Bluez-devel] Service level security for RFCOMM
@ 2004-10-29 14:36 Bhatt Abhi-ABHATT
  2004-10-29 14:47 ` Marcel Holtmann
  0 siblings, 1 reply; 20+ messages in thread
From: Bhatt Abhi-ABHATT @ 2004-10-29 14:36 UTC (permalink / raw)
  To: 'Stephen Crane', Marcel Holtmann; +Cc: BlueZ Mailing List

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
steve.crane@rococosoft.com +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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 20+ messages in thread
* [Bluez-devel] Service level security for RFCOMM
@ 2004-10-29  4:42 Marcel Holtmann
  2004-10-29  4:46 ` James Cameron
  2004-10-29  9:31 ` Stephen Crane
  0 siblings, 2 replies; 20+ messages in thread
From: Marcel Holtmann @ 2004-10-29  4:42 UTC (permalink / raw)
  To: BlueZ Mailing List

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 20+ messages in thread
end of thread, other threads:[~2004-11-01 12:17 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-10-29 20:04 [Bluez-devel] Service level security for RFCOMM Bhatt Abhi-ABHATT
2004-10-29 20:22 ` Marcel Holtmann
     [not found] <5987A7CB1694D811A04D0002B32C289601BF3C03@il93exb05.corp.mot.com>
2004-10-29 19:41 ` Marcel Holtmann
  -- strict thread matches above, loose matches on Subject: below --
2004-10-29 15:35 Bhatt Abhi-ABHATT
2004-10-29 15:53 ` Stephen Crane
2004-10-29 17:05   ` Marcel Holtmann
2004-10-29 17:02 ` Marcel Holtmann
2004-10-29 14:36 Bhatt Abhi-ABHATT
2004-10-29 14:47 ` Marcel Holtmann
2004-10-29 15:10   ` Stephen Crane
2004-10-29 16:40     ` Marcel Holtmann
2004-11-01 12:02       ` Stephen Crane
2004-11-01 12:17         ` Marcel Holtmann
2004-10-29  4:42 Marcel Holtmann
2004-10-29  4:46 ` James Cameron
2004-10-29  4:55   ` Marcel Holtmann
2004-10-29  9:31 ` Stephen Crane
2004-10-29 10:34   ` Fred Schaettgen
2004-10-29 12:10     ` Marcel Holtmann
2004-10-29 12:02   ` Marcel Holtmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox