From: Anupam Roy <anupam.r@samsung.com>
To: "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Cc: Semun Lee <semun.lee@samsung.com>,
Dohyun Pyun <dh79.pyun@samsung.com>,
Nitin Jhanwar <nitin.j@samsung.com>
Subject: Regarding OOB authentication method & action for Mesh provisioner
Date: Mon, 02 Mar 2020 18:23:44 +0530 [thread overview]
Message-ID: <20200302125344epcms5p3e31d97ef6263e0513b94f6306536269b@epcms5p3> (raw)
In-Reply-To: CGME20200302125344epcms5p3e31d97ef6263e0513b94f6306536269b@epcms5p3
Hello,
Regarding remote node provisioning, currently, it seems 'meshd' is choosing Provisioning method & actions internally, based on remote node's capabilities.
- Choosing Method :- /* Parse OOB Options, prefer static, then out, then in */
- Choosing Action:- Based on high bit set in the action octet: u16_high_bit(l_get_be16(data + 6)), in case of OUT OOB or u16_high_bit(l_get_be16(data + 9)) in case of IN OOB
Is the above preference for choosing Authentication Method, based on some pre-defined security level? If yes, can such security levels can be made available to application for configuration?
Also, I would like to know, whether there is any plan to Request external provisioning Agent to choose Provisioning method & specific action?
The reason being, some *application* may be interested in a particular Security level & Authentication action, depending on its own I/O capabilities.
BR,
-Anupam Roy
BR,
-Anupam Roy
next parent reply other threads:[~2020-03-02 12:54 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20200302125344epcms5p3e31d97ef6263e0513b94f6306536269b@epcms5p3>
2020-03-02 12:53 ` Anupam Roy [this message]
2020-03-02 14:22 ` Regarding OOB authentication method & action for Mesh provisioner Michał Lowas-Rzechonek
[not found] ` <CGME20200302125344epcms5p3e31d97ef6263e0513b94f6306536269b@epcms5p7>
2020-03-02 14:55 ` Anupam Roy
2020-03-02 16:56 ` Gix, Brian
2020-03-02 17:15 ` Stotland, Inga
2020-03-02 17:31 ` Gix, Brian
2020-03-03 8:55 ` michal.lowas-rzechonek
[not found] ` <CGME20200302125344epcms5p3e31d97ef6263e0513b94f6306536269b@epcms5p1>
2020-03-03 9:18 ` Re: " Anupam Roy
2020-03-03 18:26 ` Gix, Brian
[not found] ` <CGME20200302125344epcms5p3e31d97ef6263e0513b94f6306536269b@epcms5p4>
2020-03-04 14:52 ` Anupam Roy
2020-03-27 13:47 ` RE: Re: Mesh Key Refreshment procedure from Config client Anupam Roy
2020-03-30 6:04 ` Stotland, Inga
[not found] ` <CGME20200302125344epcms5p3e31d97ef6263e0513b94f6306536269b@epcms5p5>
2020-03-31 8:05 ` Anupam Roy
2020-03-27 5:35 ` Anupam Roy
[not found] <20200326144743epcms5p401053700dae86ae93749df5fc77a2807@epcms5p4>
[not found] ` <20200304153920epcms5p47e26659f715177b0244f18c71e4b5fed@epcms5p4>
[not found] ` <CGME20200302125344epcms5p3e31d97ef6263e0513b94f6306536269b@epcms5p2>
2020-03-26 14:52 ` Anupam Roy
2020-03-27 5:10 ` Stotland, Inga
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200302125344epcms5p3e31d97ef6263e0513b94f6306536269b@epcms5p3 \
--to=anupam.r@samsung.com \
--cc=dh79.pyun@samsung.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=nitin.j@samsung.com \
--cc=semun.lee@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.