iot-onboarding / rabble

RAdius profile for Bonded Bluetooth Low Energy (Rabble)

rabble

Radius profile for Bonded Bluetooth Low Energy (Rabble)

Note Well

This is a reminder of IETF policies in effect on various topics such as patents or code of conduct. It is only meant to point you in the right direction. Exceptions may apply. The IETF's patent policy and the definition of an IETF "contribution" and "participation" are set forth in BCP 79; please read it carefully.

As a reminder:

By participating in the IETF, you agree to follow IETF processes and policies.

If you are aware that any IETF contribution is covered by patents or patent applications that are owned or controlled by you or your sponsor, you must disclose that fact, or not participate in the discussion.

As a participant in or attendee to any IETF activity you acknowledge that written, audio, video, and photographic records of meetings may be made public.

Personal information that you provide to IETF will be handled in accordance with the IETF Privacy Statement.

As a participant or attendee, you agree to work respectfully with other participants; please contact the ombudsteam (https://www.ietf.org/contact/ombudsteam/) if you have questions or concerns about this.

Definitive information is in the documents listed below and other IETF BCPs. For advice, please talk to WG chairs or ADs:

• BCP 9 (Internet Standards Process)

• BCP 25 (Working Group processes)

• BCP 25 (Anti-Harassment Procedures)

• BCP 54 (Code of Conduct)

• BCP 78 (Copyright)

• BCP 79 (Patents, Participation)

• https://www.ietf.org/privacy-policy/ (Privacy Policy)

rabble's Issues

radex mailer: quick review

Just a review based on scanning it quickly.

• I don't see a need for a long list of "this attribute isn't used by BLE authenticators". If it's not used, it can be omitted

• There's no need to re-define what the attributes are.

• e.g. User-Password is encrypted. Just state what it contains.

• Called-Station-Id already has a defined format in RFC 3580 section 3.20.

• Generally just say "This attribute has value X". There's no need for exhaustive lists and re-redefinitions

• for new attributes, RFC 8044 says we can skip the ASCII art. Just define the name and the data type.

  Using extended attributes makes ASCII art more difficult, so less work is better work

• BLE-Keying-Material is a complex structure. See https://www.rfc-editor.org/rfc/rfc6158#section-3.2.3

  If it's possible to just reference another specification for the format, that would be best. i.e. if the RADIUS client/server don't need to decode the fields of this structure, then it should be defined as an opaque blob. That blob can be obtained from something else by the RADIUS server, and sent by the RADIUS client to something else.

  If the fields need to be understood by the RADIUS client/server, then it may be better to separate them out into individual attributes.

  It's not clear why this attribute requires a Message-Authenticator to be present. The Message-Authenticator is really useful only for Access-Request packets, which otherwise have no signatures. In reply packets like Access-Accept, etc. Message-Authenticator offers little value.

  The "Keying Material Data" field should arguably be "protected" with the attribute obfuscation defined for User-Password. It's ugly, but it's what we have.

radext mailer: authentication scheme

Have you considered stronger alternatives to your authentication scheme? The protection afforded to six bytes by RFC2865 is arguably weak.

Use of the word "decode" is confusing

We say (for example):

The NAS/BLE Visited Central Host decodes the Advertisement(s) sent by the BLE Peripheral and MAY use the presence and/or contents of specific Advertising Elements to decide whether to trigger a RADIUS exchange with a RADIUS Server which has access to the keying material exposed by the BLE Home Central Host.

We don't mean decrypting, but parsing.

need more detail on the GATT advertisement for identifying home network

Subject says it all. Currently not specified in any detail.