OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] (MQTT-330) Bad bookmark: 'TLS [RFC5246]', line 1488 actually points to [RFC6455]

    [ https://issues.oasis-open.org/browse/MQTT-330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=64999#comment-64999 ] 

Ken Borgendale commented on MQTT-330:

This is a reference error in non-normative text which is an editing error (the hyperlink does not go to where the text says it should).  This was fixed in the MQTTv5.0 working drafts.

> Bad bookmark: 'TLS [RFC5246]', line 1488 actually points to [RFC6455] 
> ----------------------------------------------------------------------
>                 Key: MQTT-330
>                 URL: https://issues.oasis-open.org/browse/MQTT-330
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: edits
>    Affects Versions: 3.1.1
>            Reporter: Brian Raymor
>            Assignee: Rahul Gupta
>            Priority: Trivial
>             Fix For: 3.1.1
> This error does not appear in the MQTT v5 draft.
> Forwarded to mqtt-comment by Robin Cover:
> As reported (via Paul Fremantle), though I did not thoroughly check out::
> This: (",... Where TLS [RFC5246] is used,  "_
> http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/errata01/os/mqtt-v3.1.1-errata01-os-complete.html#RFC5246
> http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#RFC5246
> seems to link to reference ==
> [RFC6455]
> Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011.
> http://www.ietf.org/rfc/rfc6455.txt
> ==========
> 5.4.1 Authentication of Clients by the Server
> The CONNECT Packet contains Username and Password fields. Implementations can choose how to make use of the content of these fields. They may provide their own authentication mechanism, use an external authentication system such as LDAP [RFC4511] or OAuth [RFC6749] tokens, or leverage operating system authentication mechanisms.
> Implementations passing authentication data in clear text, obfuscating such data elements or requiring no authentication data should be aware this can give rise to Man-in-the-Middle and replay attacks. Section 5.4.5 introduces approaches to ensure data privacy.
> A Virtual Private Network (VPN) between the Clients and Servers can provide confidence that data is only being received from authorized Clients.
> Where TLS [RFC5246] is used, SSL Certificates sent from the Client can be used by the Server to authenticate the Client.
> - Robin
> Well caught. Hopefully someone on the OASIS committee will fix this in the Errata. However, I'm not sure the inter-PDF links are considered part of the normative nature of the document?
> Paul
> On 7 January 2017 at 09:35, Jianming Lin <jianming.ln@gmail.com> wrote:
> Hi there,
> I'm not sure whether it's really a typo.
> But, the 'TLS [RFC5246]', line 1488 actually points to [RFC6455], line 70, which just following the right one.
> It actually confused me and took me some time to figure it out, though may not be a serious issue.

This message was sent by Atlassian JIRA

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]