IEC 62481-7-2017 pdf free.Digital living network alliance (DLNA) home networked device interoperability guidelines – Part 7: Authentication.
This part of IEC 62481 specifies DLNA interoperability guidelines for device authentication.
The DLNA interoperability guidelines are based on a device authentication solution, which is defined as methods to enable authentication of a client device as DLNA Certified. Methods are included to allow a client device to authenticate a server device as trusted by a Certificate Authority.
The guidelines are intended to supplement other interoperability mechanisms already defined for DLNA link protection and DLNA DRM interoperability solutions.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
5.4 System usages
DLNA Authentication guidelines are designed to complement all DLNA Device Classes and Device Capabilities in all system usages, providing and enabling them the ability to authenticate each other securely before other functions, such as content transports, can be performed. Other than adding the authentication processes as described in 3.1.3 and 3.1.5, all DLNA system usages stay the same.
While some of the implementations of DLNA system usages require device authentication. many do not. As such, DLNA Authentication guidelines are optional (also known as Device Options) and it is an implementer’s choice to implement them.
Although an Authentication Server or an Authentication Client may be implemented as an independent entity that performs authentication only without any other function, this type of implementation does not make sense because there is no purpose to authenticate It. Therefore, the authentication services are designed as Device Options that shall be a part of a Device Class or Device Capability when implemented.
5.5 Theory of operation
The enclosed guidelines enable the ability for a server to authenticate a client as a DLNA certified device using either X.509 credentials or device certificates. Conversely, the ability for a client to authenticate a server is also supported. The TLS protocol using the SupplementalData payload mechanism is defined herein to support both client and server authentication using DTCP certificates.
The authentication scenarios covered are as follows.
1. Server uses trusted X.509 and client uses trusted X.509.
2. Server uses trusted X.509 and client uses DTCP.
3. Server uses (trusted or self-signed X.509) + DTCP. and client uses trusted X.509.
4. Server uses (trusted or self-signed X.509) + DTCP, and client uses DTCP.
The first scenario is supported by a standard TLS protocol. The rest of the scenarios require use of SupplementalData extensions to the TLS protocol. Scenario #3 is highly unlikely to occur in practice due to the typical nature of a TLS handshake. A TLS handshake is triggered by a TLS client sending a ClientHello message and if the TLS client does not indicate support for the DTCP method, a TLS server will not be allowed to send the DTCP certificate. So a TLS client is required to have a priori knowledge that a particular TLS server is using a DTCP certificate.IEC 62481-7 pdf download.