DLNA Guidelines March 2014

(1)

DLNA Guidelines

March 2014

Part 7: Authentication

An Industry Guide for

Building Interoperable

Platforms, Devices,

and Applications

Fulfilling the promise of the digital home requires a c ross -industry effort to develop and promote a c ommon industry framework for interoperability. This industry framework is ex press ed through the DLNA Guidelines doc ument that has been developed to provide Cons umer Electronic, Mobile Devic e and PC c ompanies with the information needed to build interoperable platforms , devic es , and applic ation for the digital home.

(2)

DLNA Guidelines ; Part 7: Authentic ation

Legal Disclaimer

NOTHING CON TAINED IN THIS DOCUMENT SHALL BE DEEMED AS GRANTING YOU ANY KIND OF LICENSE IN ITS CONTENT, EITHER EXPRESSLY OR IMPLIEDLY, OR TO ANY INTELLECTUAL PROPERTY OW NED OR CONTROLLED BY ANY OF THE AUTHORS OR DEVELOPERS OF THIS DOCUMENT. THE INFORMATION CONTAINED HEREIN IS PROVIDED ON AN "AS IS" BASIS, AND TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE AUTHORS AND DEVELOPERS OF THIS SPECIFICATION HEREBY DISCLAIM ALL OTHER WARRANTIES AND CONDITIONS, EITHER EXPRESS OR IMPLIED, STATUTORY OR AT COMMON LAW, INCLUDING, BUT NOT LIMITED TO, IMPLIED W ARRANTIES OF MERCHANTABILITY OF FITNESS FOR A PARTICULA R PURPOSE. DLNA FURTHER DISCLAIMS ANY AND ALL WARRANTIES OF NONINFRINGEMENT, ACCURACY OR LACK OF VIRUSES.

DLNA, DLNA CERTIFIED, and the logo are trademarks, regis tered trademarks, or s ervic emarks of Digital Living Network Allianc e in the United State or o ther c ountries.

(3)

DIGITAL LIVING NETWORK ALLIANCE (DLNA) GUIDELINES

Part 7: Authentication

1 Scope

This part of IEC 62481 s pec ifies DLNA interoperability guidelines for devic e authentic ation. The DLNA interoperability guidelines are bas ed on a devic e authentic ation s olution, whic h is defined as methods to enable authentic ation of a client devic e as DLNA Certified. Methods are included to allow a client devic e to authentic ate a s erver devic e as trus ted by a Certific ate Authority.

The guidelines are intended to s upplement other interoperability mec hanis ms already defined for DLNA link protec tion and DLNA DRM interoperability s olutions .

2 Normative References

The following doc uments, in whole or in part, are normatively referenc ed in this doc ument and are indis pens able for its applic ation. For dated referenc es , only the edition c ited applies. For undated referenc es , the latest edition of the referenc ed doc ument (including any amendments ) applies .

IEC 62481-1, Digital living network allianc e (DLNA) home network ed devic e interoperab ility

guidelines - P art 1: A rc hit ec ture and prot oc ols

IETF RFC 2616, Hypertext Trans fer Protoc ol, http://www.ietf.org/rfc /rfc2616.tx t

IETF RFC 2818, HTTP over TLS , Informational, http://tools.ietf.org/html/rfc2818

IETF RFC 4680, TLS Hands hak e Mes s age for Supplemental Data , http://tools.ietf.org/html/rfc4680

IETF RFC 5246, The Trans port Layer Sec urity (TLS) Protoc ol Vers ion 1.2 , http://tools.ietf.org/html/rfc5246

IETF RFC 5280, Internet X.509 Public Key Infrastruc ture Certific ate and Certific ate Revoc ation

Lis t (CRL) P rof ile,

http://tools.ietf.org/html/rfc5280

IETF RFC 5878, Trans port Layer Sec urity (TLS) Authorization Extensions , http://tools.ietf.org/html/rfc5878

IETF RFC XXXX, <TDB> Authentication Credential Exc hange Us ing TLS Supplemental Data , https ://datatracker.ietf.org/doc /draft-dthakore-tls-authz/

DTCP Volume 1 (informational vers ion), Digital Trans miss ion Content Protection Spec ific ation

V olume 1, Revis ion 1. 7,

http://www.dtcp.c om/doc uments /dtcp/info -20111214-dtcp-v1-rev-1-p-7.pdf

3 T e rms, de finitions, symbols and abbreviated terms

For the purpos es of this doc ument, the terms, definitions, symbols and abbreviated terms in IEC 62481-1 and the following apply .

3. 1 Ge ne ral Te rms

3. 1. 1 Authe nti cation Cl i ent

a s et of devic e func tions , as part of the Client Authentic ation Devic e Option, provides the protoc ols to allow a c lient to be authentic ated and the protoc ols to authentic ate an Authentication Server by verify ing the Server c redentials .

(6)

2

3. 1. 2 Authe nti cation S erver

a Devic e Function that, as part of the Server Authentic ation Devic e Option, provides the protoc ols to allow a server to be authentic ated and the protoc ols to authentic ate an Authentication Client by verify ing the Client c redentials.

3. 1. 3 Cl i e nt Authe ntication

proc ess or action where the Authentic ation Client initiates the authentic ation request for the Authentication Server to authentic ate the Client.

3. 1. 4 DTCP Me thod

oc c urs when a devic e us es a devic e c ertific ate for its elf during DLNA Authentication

3. 1. 5 S e rve r Authentication

proc ess or ac tion where the Authentic ation Server is authentic ated by the Authentic ation Client

3. 1. 6 X . 509 Me thod

occ urs when a devic e us es an X.509 c redential for its elf during DLNA Authentic ation. No DTCP devic e c ertific ate is us ed with this method

3. 2 Conve nti ons

In IEC 62481-1 and this doc ument, a number of terms , c onditions, mec hanisms, s equenc es, parameters, events, s tates, or similar terms are printed with the first letter of eac h word in upperc as e and the rest lowerc as e (e.g. Move.) Any lowerc as e us es of thes e words have the normal tec hnic al English meanings .

4 Ne tworking Architecture and Guideline Conventions

4. 1 DLNA Hom e Ne tw orking Archi tecture

This doc ument ex tends the DLNA Home Networking Arc hitecture that is defined in claus e 4, IEC 62481-1.

4. 2 Docum e nt conve ntions

See c laus e 6, IEC 62481-1, for a des c ription of t he DLNA doc ument c onventions .

4. 3 Gui de l ine structure

See c laus e 7.1 in IEC 62481-1, for guideline and attribute table lay out des criptions .

5 DLNA De v ice M odel

Refer to c laus e 5, IEC 62481-1, for detailed desc riptions of ex isting DLNA Home Networking Arc hitecture Devic e Model. This doc ument ex tends the ex isting DLNA Sy s tem Us ages.

5. 1 Authe nti cation De vice Functi ons

The arc hitecture c ons ists of sys tem elements in the home and outs ide the home us ed to implement the DLNA authentic ation feature. Thes e elements s upport both s ervic e provider and home owner us e c as es . Figure 1 is an overview of the arc hitec ture.

(7)

Fi gure 1 —Authe nti ca ti on functi ons

The arc hitec ture defines the following func tions .

Credential Authority – Creates client and s erver c redentials for us e by manufacturers in their devic es. Provides root c ertific ate(s ) to the Authentic ation Server and the Authentic ation Client . Defines the robus tnes s requirements.

Client Credential Installation – Ins talls the c redentials into the c lient devic e. Performed by the manufac turer.

Client Credential Storage – Stores the c redentials acc ording to the robustness requirements . Provides ac c es s to the c redentials by the Authentication Server.

Server Credential Storage – Stores the c redentials acc ording to the robustness requirements . Provides ac c es s to the c redentials by the Authentication Server.

Authentic ation Client – Authentic ates with the Authentic ation Server and authentic ates s ervers us ing the Server Credentials .

Authentic ation Server – Authentic ates with the Authentic ation Client and authentic ates c lients us ing the Client Credentials.

Server

Authentication

Device Option

Credential

Ins tallation

Credential

Authority

Specified

Unspecified

Se rve r

Cre de nti al

Storage

Authentication

Se rve r

Client

Authentication

Device Option

Cl i e nt

Cre de nti al

Storage

Authenticati on

Cl i ent

(8)

4

The DLNA guidelines will c over interoperability between the Authentic ation Client Function and the Authentic ation Server Func tion.

5. 2 De vi ce Opti ons

For the Authentication Interoperability Guidelines and System Us ages , the following Devic e Options are defined.

Client Authentic ation: A Devic e Option that c onsists of an Authentic ation Client Function and Client Credentials .

Server Authentic ation: A Devic e Option that c ons ists of an Authentic ation Server Function and Server Credentials .

5. 3 S yste m Usa ge s

DLNA Authentic ation Guidelines are des igned to c omplement all DLNA Devic e Class es and Devic e Capabilities in all System Us ages , providing and enabling them the ability to authentic ate eac h other s ec urely before other func tions, s uc h as c ontent trans ports , c an be performed . Other than adding the authentic ation proc es s es as desc ribed in 3.1.3 and 3.1.5, all DLNA System Us ages s tay the s ame.

W hile s ome of the implementations of DLNA System Us ages require devic e authentic ation, many do not. As s uc h, DLNA Authentic ation Guidelines are optional (a.k.a Devic e Options ) and it is an implementer’s c hoice to implement them.

Although an Authentic ation Server or an Authentic ation Client may be implemented as an independent entity that performs authentic ation only without any other function, this ty pe of implementation does not mak e s ens e bec aus e there is no purpos e to authentic ate. Therefore, the authentic ation s ervic es are des igned as D evic e Options that s hall be a part of a Devic e Class or Devic e Capability when implemented.

5. 4 The ory of Ope ra tion

The enc los ed guidelines enable the ability for a s erver to authentic ate a client as a DLNA c ertified devic e using either X.509 c redentials or devic e c ertific ates. Convers ely the ability for a c lient to authentic ate a s erver is als o s upported. The TLS protoc ol us ing the SupplementalData pay load mec hanism is defined herein to s upport both c lient and s erver authentic ation using DTCP c ert ificates.

The authentic ation s c enarios c overed are as follows .

1. Server us es trus ted X.509 and c lient us es trusted X.509 2. Server us es trus ted X.509 and c lient us es DTCP

3. Server us es (trus ted or s elf-s igned X.509) + DTCP , and c lient us es trus ted X.509 4. Server us es (trus ted or s elf-s igned X.509) + DTCP , and c lient us es DTCP

The first sc enario is s upported by s tandard TLS protoc ol. The rest of the sc enarios require us e of SupplementalData extensions to TLS protoc ol. Sc enario #3 is highly unlikely to occ ur in practic e due to the typic al nature of a TLS hands hak e. A TLS handshak e is triggered by a TLS c lient s ending a ClientHello mess age and if the TLS client does not indic ate s upport for the DTCP method, a TLS s erver will not be allowed to s end the DTCP c ertific ate. So a TLS c lient is required to have a priori k nowledge that a partic ular TLS s erver is us ing DTCP c ertific ate .

6 Guideline requirements

6. 1 De vi ce di scove ry a nd control 6. 1. 1 Authe nti cation S erver di scovery 6. 1. 1. 1

[GUIDEL INE] A DLNA Devic e Clas s or Devic e Capability that indic ates s upport for the Server

Authentic ation Devic e Option s hall implement the requirements s pecified for Authentic ation Server.

(9)

[AT T RIBUT ES]

M A DMS, DMR, XDMR,

+RUIHSRC+ M- DMS n/a n/a W3UP4 N

[COMM ENT] Support for Server Authentic ation Devic e Option is indic ated at the time of

regis tration for c ertific ation.

6. 1. 1. 2

[GUIDEL INE] A DLNA Devic e Class or Devic e Capability t hat implements t he Aut hentic ation

Server s hall have the c apID value of “authentic ation-s erver” for the dlnac ap-value in the <dlna:X_DLNACAP> element, as defined in IEC 62481-1, of the Devic e Des c ription doc ument.

[AT T RIBUT ES]

M A DMS, DMR, XDMR,

+RUIHSRC+ M- DMS n/a IEC 62481-1 GX4I8 N

[COMM ENT] This is where a UPnP c ontrol point c hecks if the DLNA Devic e Clas s or Devic e

Capability implemented the Authentic ation Server after retrieving the Devic e Desc ription doc ument of the UPnP Devic e.

6. 1. 2 Authe nti cation Cl i ent di scove ry

[GUIDEL INE] A DLNA Devic e Class or Devic e Capability t hat indic at es s upport for t he Client

Authentic ation Devic e Option s hall implement the requirements s pecified for Authentic ation Client .

[AT T RIBUT ES]

M A DMC, DMP, XDMR, +PU+, +RUIHPL+

M- DMP M- DMC n/a n/a ENEWV N

[COMM ENT] Support for Client Authentic ation Devic e Option is indic ated at the time of

regis tration for c ertific ation.

6. 2 Authe nti cation gui del ines

6. 2. 1 Authe nti cation S erver protocol s 6. 2. 1. 1

[GUIDEL INE] The Aut hent ic at ion Server s hall implement HTTP 1. 1 Server. [AT T RIBUT ES]

M A DMS, DMR, XDMR,

+RUIHSRC+ M- DMS n/a IETF RFC 2616 7LRZ P N

[COMM ENT] The Devic e Class or Devic e Capability that implements the Authentic ation Server

c ould already have the HTTP 1.1 Server implemented. This guideline es tablis hes the basis for interoperability however other protoc ols c ould als o be us ed.

6. 2. 1. 2

[GUIDEL INE] The A ut hent ic at ion S erver s hall implement HTTP S (HTTP over TLS ). [AT T RIBUT ES]

M A DMS, DMR, XDMR, +RUIHSRC+

M- DMS n/a IETF RFC 2818 A BKQG N

(10)

6

c ould already have HTTPS implemented. This guideline establis hes the basis for interoperability however other protoc ols c ould als o be us ed.

6. 2. 1. 3

[GUIDEL INE] The A ut hent ic at ion S erver s hall implement t he TLS 1. 2 prot oc ol as defined in

IETF RFC 5246.

[AT T RIBUT ES]

M A DMS, DMR, XDMR,

+RUIHSRC+ M- DMS n/a IETF RFC 5246 WM9P4 N

6. 2. 1. 4

[GUIDEL INE] The A ut hentic ation S erver s hall implement t he TLS S upplement alDat a hands hak e

mes s age as defined in IETF RFC 4680.

[AT T RIBUT ES]

M A DMS, DMR, XDMR,

+RUIHSRC+ M- DMS n/a IETF RFC 4680 JY 8N9 N

6. 2. 1. 5

[GUIDEL INE] The A ut hentic ation S erver s hall implement t he c lient _aut hz and s erver_aut hz TLS

Hello mes s age ex tens ions as defined in IETF RFC 5878

[AT T RIBUT ES]

M- DMS n/a IETF RFC 5878 7TRPH N

[COMM ENT] W hen a s erver us es the TLS SupplementalData mess age to s end its c redentials, it

will do s o by indic ating s upport for thes e ex tens ions in the Hello mes s age.

6. 2. 2 Authe nti cation Cl i ent protocols 6. 2. 2. 1

[GUIDEL INE] The A ut hent ic at ion Client s hall implement HTTP 1. 1 Client . [AT T RIBUT ES]

M A DMC, DMP, XDMR, +PU+, +RUIHPL+

M- DMP M- DMC n/a IETF RFC 2616 ME837 N

[COMM ENT] The Devic e Class or Devic e Capability that implements the Authentic ation Client

c ould already have the HTTP 1.1 Client implemented. This guideline establis hes the bas is for interoperability however other protoc ols c ould als o be us ed.

6. 2. 2. 2

[GUIDEL INE] The Aut hent ic at ion Client s hall implement HTTP S (HTTP over TLS ). [AT T RIBUT ES]

M A DMC, DMP, XDMR,

+PU+, +RUIHPL+ M- DMP M- DMC n/a IETF RFC 2818 8USPH N

[COMM ENT] The Devic e Class or Devic e Capability that implements the Authentic ation Client

c ould already have HTTPS implemented. This guideline establis hes the basis for interoperability however other protoc ols c ould als o be us ed.

6. 2. 2. 3

[GUIDEL INE] The Aut hent ic ation Client s hall implement t he TLS 1. 2 prot oc ol as defined in

(11)

[AT T RIBUT ES]

M A DMC, DMP, XDMR,

+PU+, +RUIHPL+ M- DMP M- DMC n/a IETF RFC 5246 BC6Y Y N

6. 2. 2. 4

[GUIDEL INE] An Aut hent ic at ion Client that implements the DTCP Method s hall implement the

TLS SupplementalData hands hake mes sage as defined in IETF RFC 4680.

[AT T RIBUT ES]

M A DMC, DMP, XDMR,

+PU+, +RUIHPL+ M- DMP M- DMC n/a IETF RFC 4680 GM2LB N

6. 2. 2. 5

[GUIDEL INE] An Aut hent ic at ion Client that implements the DTCP Method s hall implement the

c lient_authz and s erver_authz TLS Hello mes s age ex tens ions as defined in IETF RFC 5878

[AT T RIBUT ES]

M A DMC, DMP, XDMR,

+PU+, +RUIHPL+ M- DMP M- DMC n/a IETF RFC 5878 TCEMN N

[COMM ENT] W hen a client uses the TLS SupplementalData mess age to s end its c redentials, it

will do s o by indic ating s upport for the s e ex tens ions in the Hello mes s age.

6. 2. 3 Cl i e nt Authe ntication gui delines 6. 2. 3. 1

[GENERAL] 6. 2. 3 defines all func t ionality required for performing Client A ut hent ication. 6. 2. 3. 2

[GUIDEL INE] An Aut hent ic at ion Client s hall implement one of t he following aut hentic ation

methods for c lient authentication: X.509 Method as defined in 6.2.3.3.

DTCP Method as defined in 6.2.3.5 through 6.2.3.6.

[AT T RIBUT ES]

M A DMC, DMP, XDMR,

+PU+, +RUIHPL+ M- DMP M- DMC n/a n/a A Q7A C N

[COM M ENT ] Authentication oc c urs via one of 2 s eparate c redential mec hanisms .

6. 2. 3. 3

[GUIDEL INE] If an A ut hent ic at ion Client implement s the X. 509 Met hod as defined in

IETF RFC 5280 for Client Authentic ation, then it s hall s upport TLS1.2 for Client Authentic ation as defined in IETF RFC 5246. [AT T RIBUT ES] M A DMC, DMP, XDMR, +PU+, +RUIHPL+ M- DMP M- DMC n/a IETF RFC 5246 IETF RFC 5280 LWI79 N 6. 2. 3. 4

[GUIDEL INE] If an Aut hentic ation Client implement s t he DTCP Met hod, t hen it shall implement

all c lient requirements defined in IETF RFC XXXX inc luding generating, proc es sing and error handling of SupplementalData mes sages.

(12)

8

[AT T RIBUT ES]

M A DMC, DMP, XDMR,,

+PU+, +RUIHPL+ M- DMP M- DMC n/a IETF RFC XXXX 52Z EM N

6. 2. 3. 5

[GUIDEL INE] If an Aut hent ic ation Client implements the DTCP Met hod, t hen it s hall us e the TLS

SupplementalData Double Hands hak e as defined in IETF RFC XXXX.

[AT T RIBUT ES]

M A DMC, DMP, XDMR,

+PU+, +RUIHPL+ M- DMP M- DMC n/a IETF RFC XXXX L8SLI N

6. 2. 3. 6

[GUIDEL INE] If an A ut hentic at ion Client implements the DTCP Met hod, then it s hall generat e

the SupplementalData mess age as defined in IETF RFC XXXX that includes the devic e c ertific ate as defined in DTCP Volume 1.

[AT T RIBUT ES]

M A DMC, DMP, XDMR,

+PU+, +RUIHPL+ M- DMP M- DMC n/a IETF RFC XXXXDTCP V olume 1 QA 9QL N

[COMM ENT] The devic e c ertific ate will include s uffic ient information that authentic ates the

c lient .

6. 2. 3. 7

[GUIDEL INE] An Aut hent ic at ion Server s hall implement t he DTCP Met hod as defined in 6. 2. 3. 5

for Client Authentication.

[AT T RIBUT ES]

M- DMS n/a IETF RFC 5246 R9BV I N

6. 2. 3. 8

[GUIDEL INE] An Aut hent ic at ion Server s hall implement t he X. 509 Met hod as defined in 6. 2. 3. 3

for Client Authentication.

[AT T RIBUT ES]

M- DMS n/a IETF RFC 5246 V 224M N

6. 2. 4 S e rve r Authentication gui del ines 6. 2. 4. 1

[GENERAL] 6. 2. 4 defines all func t ionality required for performing s erver aut hent ic ation. 6. 2. 4. 2

[GUIDEL INE] An Authentic at ion Server s hall implement one of t he following aut hentic ation

methods for Server Authentic ation: X.509 Method as defined in 6.2.4.3.

DTCP Method as defined in 6.2.4.4 through 6.2.4.6.

[AT T RIBUT ES]

(13)

[COMM ENT] Authentic ation occ urs via one of 2 s eparate credential mec hanisms. An

Authentic ation Server us ing devic e c ertificates als o provides an X.509 c redential in order to establis h a s ec ure TLS s ess ion. The c lient c an determine the authentication method bas ed on the pay load of the SupplementalData mes sage.

6. 2. 4. 3

[GUIDEL INE] If an A ut hent ic at ion S erver implement s the X. 509 Met hod as defined in

IETF RFC 5280 for Server Authentic ation then it shall s upport TLS 1.2 for Server Authentic ation as defined in IETF RFC 5246. [AT T RIBUT ES] M A DMS, DMR, XDMR, +RUIHSRC+ M- DMS n/a IETF RFC 5246 IETF RFC 5280 OGMFZ N

[COM M ENT ] The X.509 c redential inc ludes s uffic ient information to authenticate the s erver.

6. 2. 4. 4

[GUIDEL INE] If an A ut hent ic at ion S erver indic at es s upport for t he s erver_aut hz ext ens ion as

defined in IETF RFC 5878, then it s hall als o indic ate support for the client_authz extension as defined in IETF RFC 5878.

[AT T RIBUT ES]

M- DMS n/a IETF RFC 5878 SEA U2 N

[COMM ENT] The s erver_authz and c lient_authz ex tensions are c arried within the

SupplementalData pay load.

6. 2. 4. 5

[GUIDEL INE] The A ut hentic ation S erver s hall implement all s erver requirements defined in 3. 4

of IETF RFC XXXX inc luding generating, proc essing and error handling of SupplementalData mes s ages .

[AT T RIBUT ES]

M A DMS, DMR, XDMR,

+RUIHSRC+ M- DMS n/a IETF RFC XXXX TUX52 N

6. 2. 4. 6

[GUIDEL INE] If an A ut hentic ation S erver implements the DTCP Met hod for S erver

Authentic ation, then it s hall c reate and s end the SupplementalData mess age that includes the devic e c ertific ate as per IETF RFC XXXX.

[AT T RIBUT ES] M A DMS, DMR, XDMR, +RUIHSRC+ M- DMS n/a IETF RFC XXXX DTCP V olume 1 Z OETF N

[COMM ENT] The devic e c ertific ate will include s uffic ient information that authentic ates the

s erver.

6. 2. 4. 7

[GUIDEL INE] An Aut hentic ation Client s hould implement t he DTCP Met hod as defined in 6. 2. 4. 6

for Server Authentic ation.

(14)

10

DLNA Guidelines ; Part 7: Authentic ation S A DMC, DMP, XDMR,

+PU+, +RUIHPL+

M- DMP M- DMC n/a IETF RFC 5246 4V RO9 N

[COMM ENT] A Client Authentic ation Devic e Option will determine the authentic ation method the

Server s upports and res pond ac c ordingly.

6. 2. 4. 8

[GUIDEL INE] An Aut hentic ation Client s hould implement t he X. 509 Met hod as defined in 6. 2. 4. 3

for Server Authentic ation.

[AT T RIBUT ES]

S A DMC, DMP, XDMR, +PU+, +RUIHPL+

M- DMP M- DMC n/a IETF RFC 5246 CA V 9Q N

[COMM ENT] A Client Authentic ation Devic e Option will determine the authentic ation method the

DLNA Guidelines March 2014

DLNA Guidelines

March 2014

Part 7: Authentication

An Industry Guide for

Building Interoperable

Platforms, Devices,

and Applications

Legal Disclaimer

CONTENTS

DIGITAL LIVING NETWORK ALLIANCE (DLNA) GUIDELINES

Part 7: Authentication

1 Scope

2 Normative References

3 T e rms, de finitions, symbols and abbreviated terms

4 Ne tworking Architecture and Guideline Conventions

5 DLNA De v ice M odel

Server

Authentication

Device Option

Credential

Ins tallation

Credential

Authority

Specified

Unspecified

Se rve r

Cre de nti al

Storage

Authentication

Se rve r

Client

Authentication

Device Option

Cl i e nt

Cre de nti al

Storage

Authenticati on

Cl i ent

6 Guideline requirements