Subject: [core] CoAP Option for Authentication Token

From: Patrick Barrett <[email-masked]>
Date: Thu, 10 Jul 2014 17:03:43 -0500

Our company is currently in the process of porting our HTTP API over
to CoAP. With our current API we use an HTTP header (X-Exosite-CIK)
for sending an auth token and in our current CoAP implementation we're
just sending this as a query parameter. Since we'd like the option of
sending it in a raw binary value from to save bytes, it's my
understanding that this actually violates the protocol since it isn't
guaranteed to be valid UTF-8. The only two options in the main RFC
that allow opaque byte strings (If-Match and ETag) don't seem
appropriate and don't allow long enough values. I looked through the
other drafts and didn't see any that added options that seemed more
appropriate. I also looked at the IANA registry, but that seems to
only have the options from the RFC.

Is there an existing option that would be appropriate for this use? If
not what is the process for proposing one? I'm not fimilar with what
the terms "IETF Review or IESG Approval", "Specification Required", or
"Expert Review" mean. I'm willing to help in any way I can.

Thanks

-- 
Patrick Barrett  //  E X O S I T E  //  Minneapolis, MN  //  www.exosite.com

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 11 Jul 2014 00:47:26 +0200

Hi Patrick,

I think others will comment on whether it is wise to send authentication tokens in the clear.
Brace for impact… :-)

I’ll just try to answer these questions:

On 11 Jul 2014, at 00:03, Patrick Barrett <[email-masked]> wrote:

> Is there an existing option that would be appropriate for this use?

I don’t think so.
There is an active discussion about node-IDs, and maybe something coming out of that discussion will come close, but that may be too late for you.

> If
> not what is the process for proposing one?

If you want to have a “standard” one that everybody else will also want to use, you just have started that process, but it might take a while.

If you really just want one for use between consenting implementations, you could go for one of these (section 12.2):

          |    256-2047 | Specification Required                |
          |  2048-64999 | Expert Review                         |

Specification required means that you have written up in a stable form what the option is supposed to do, so others have a chance to implement it in an interoperable way (you can review

	http://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml

for a related registry that is just a bit further along in the process).  Expert review just means there will be a review "to help ensure that the option semantics are defined correctly” — that may be a very useful review.

In both cases, you use the form at

	http://www.iana.org/cgi-bin/assignments.pl

to submit the request.  If you want to be nice, you send a heads-up beforehand to

	[email-masked]

(after subscribing at

	https://www.ietf.org/mailman/listinfo/core-parameters

so you see any ensuing discussion.  Don’t worry, the list traffic will not kill you…)

Grüße, Carsten

---

From: Patrick Barrett <[email-masked]>
Date: Thu, 10 Jul 2014 19:22:09 -0500

> I think others will comment on whether it is wise to send authentication tokens in the clear.

I am aware, but we support it for devices like Arduino that don't
support DTLS. Regardless, my soul is prepared for the incoming
opinions.

> There is an active discussion about node-IDs, and maybe something coming out of that discussion will come close, but that may be too late for you.

That looks like it may be a good option. Although it does claim that
the format is string, but then it says that "The value can be in the
form of Binary bits...", so maybe they actually intend for it to be an
opaque format.

> so you see any ensuing discussion.  Don’t worry, the list traffic will not kill you…)

Thanks for taking the time to detail all this out for me.

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 14 Jul 2014 09:42:03 +0200

> "Expert Review" mean. I'm willing to help in any way I can.

Hello Patrick,

we considered a similar thing a while ago: sending autorization tokens 
via CoAP options. One issue seems to be that fragmentation only works 
for payload, not for options, so depending on the length of your token 
you might run into trouble.

Regards,

Ludwig

Shameless plug: If you are interested in authentication and 
authorization for CoRE, I invite you to join the discussion of the ACE 
working group (https://datatracker.ietf.org/wg/ace). I'm sure the WG 
would very much like to hear about your usecase.

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se