idnits 2.17.1 draft-ietf-hokey-key-mgm-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1, 2009) is 5412 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 5296 (Obsoleted by RFC 6696) ** Obsolete normative reference: RFC 5226 (ref. 'IANA') (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Hoeper, Ed. 3 Internet-Draft Motorola 4 Intended status: Standards Track Y. Ohba, Ed. 5 Expires: January 2, 2010 Toshiba 6 July 1, 2009 8 Distribution of EAP based keys for handover and re-authentication 9 draft-ietf-hokey-key-mgm-07 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on January 2, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This document describes a mechanism for delivering root keys from an 58 Extensible Authentication Protocol (EAP) server to another network 59 server that requires the keys for offering security protected 60 services, such as re-authentication, to an EAP peer. The distributed 61 root key can be either a usage-specific root key (USRK), a domain- 62 specific root key (DSRK) or a domain-specific usage-specific root key 63 (DSUSRK) that has been derived from an Extended Master Session Key 64 (EMSK) hierarchy previously established between the EAP server and an 65 EAP peer. The document defines a key distribution exchange (KDE) 66 protocol that can distribute these different types of root keys over 67 AAA and discusses its security requirements. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Key Delivery Architecture . . . . . . . . . . . . . . . . . . 6 74 4. Key Distribution Exchange (KDE) . . . . . . . . . . . . . . . 7 75 4.1. Context and Scope for Distributed Keys . . . . . . . . . . 8 76 4.2. Key Distribution Exchange Scenarios . . . . . . . . . . . 8 77 5. KDE used in the EAP Re-authentication Protocol (ERP) . . . . . 9 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 6.1. Requirements on AAA Key Transport Protocols . . . . . . . 10 80 6.2. Distributing RK without Peer Consent . . . . . . . . . . . 10 81 7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 11 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 83 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 86 10.2. Informative references . . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 89 1. Introduction 91 The Extensible Authentication Protocol (EAP) [RFC3748] is an 92 authentication framework supporting authentication methods that are 93 specified in EAP methods. By definition, any key-generating EAP 94 method derives a Master Session Key (MSK) and an Extended Master 95 Session Key (EMSK). [RFC5295] reserves the EMSK for the sole purpose 96 of deriving root keys that can be used for specific purposes called 97 usages. In particular, [RFC5295] defines how to create a usage- 98 specific root key (USRK) for bootstrapping security in a specific 99 application, a domain-specific root key (DSRK) for bootstrapping 100 security of a set of services within a domain, and a usage-specific 101 DSRK (DSUSRK) for a specific application within a domain. [RFC5296] 102 defines a re-authentication root key (rRK) that is a USRK designated 103 for re-authentication. 105 The MSK and EMSK may be used to derive further keying material for a 106 variety of security mechanisms [RFC5247]. For example, the MSK has 107 been widely used for bootstrapping the wireless link security 108 associations between the peer and the network attachment points. 109 However, performance as well as security issues arise when using the 110 MSK and the current bootstrapping methods in mobile scenarios that 111 require handovers, as described in [RFC5169]. To address handover 112 latencies and other shortcomings, [RFC5296] specifies an EAP re- 113 authentication protocol (ERP) that uses keys derived from the EMSK or 114 DSRK to enable efficient re-authentications in handover scenarios. 115 [RFC5295] and [RFC5296] both do not specify how root keys are 116 delivered to the network server requiring the key. Such a key 117 delivery mechanism is essential because the EMSK cannot leave the EAP 118 server ([RFC5295]) but root keys are needed by other network servers 119 disjoint with the EAP server. For example, in order to enable an EAP 120 peer to re-authenticate to a network during a handover, certain root 121 keys need to be made available by the EAP server to the server 122 carrying out the re-authentication. 124 This document specifies a mechanism for the delivery of the EMSK 125 child keys from the server holding the EMSK or a root key to another 126 network server that requests a root key for providing protected 127 services (such as re-authentication and other usage and domain- 128 specific services) to EAP peers. In the remainder of this document, 129 a server delivering root keys is referred to as Key Delivering Server 130 (KDS) and a server authorized to request and receive root keys from a 131 KDS is referred to as Key Requesting Server (KRS). The Key 132 Distribution Exchange (KDE) protocol defined in this document runs 133 over AAA (e.g. RADIUS [RFC2865], [RFC3579] or Diameter [RFC3588]) 134 and has several variants depending on the type of key that is 135 requested and delivered (i.e. DRSK, USRK, and DSUSRK). The document 136 also describes security requirements for the secure key delivery over 137 AAA. 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 USRK 146 Usage-Specific Root Key. A root key that is derived from the EMSK, 147 see [RFC5295]. 149 USR-KH 150 USRK Holder. A network server that is authorized to request and 151 receive a USRK from the EAP server. The USR-KH can be an AAA 152 server or dedicated service server. 154 DSRK 155 Domain-Specific Root Key. A root key that is derived from the 156 EMSK, see [RFC5295]. 158 DSR-KH 159 DSRK Holder. A network server that is authorized to request and 160 receive a DSRK from the EAP server. The most likely 161 implementation of a DSR-KH is an AAA server in a domain, enforcing 162 the policies for the usage of the DSRK within this domain. 164 DSUSRK 165 Domain-Specific Usage-Specific Root Key. A root key that is 166 derived from the DSRK, see [RFC5295]. 168 DSUSR-KH 169 DSUSRK holder. A network server authorized to request and receive 170 a DSUSRK from the DSR-KH. The most likely implementation of a 171 DSUSR-KH is an AAA server in a domain, responsible for a 172 particular service offered within this domain. 174 RK 175 Root Key. An EMSK child key, i.e. a USRK, DSRK, or DSUSRK. 177 KDS 178 Key Delivering Server. A network server that holds an EMSK or 179 DSRK and delivers root keys to KRS requesting root keys. The EAP 180 server together with the AAA server it exports the keys to for 181 delivery and the DSR-KH can both act as KDS. 183 KRS 184 Key Requesting Server. A network server that shares an interface 185 with a KDS and is authorized to request root keys from the KDS. 186 USR-KH, DSR-KH, and DSUSR-KH can all act as KRS. 188 3. Key Delivery Architecture 190 An EAP server carries out normal EAP authentications with EAP peers 191 but is typically not involved in potential handovers and re- 192 authentication attempts by the same EAP peer. Other servers are 193 typically in place to offer these requested services. These servers 194 can be AAA servers or other service network servers. Whenever EAP- 195 based keying material is used to protect a requested service, the 196 respective keying material has to be available to the server 197 providing the requested service. For example, the first time a peer 198 requests a service from a network server, this server acts as a KRS. 199 The KRS requests the root keys needed to derive the keys for 200 protecting the requested service from the respective KDS. In 201 subsequent requests from the same peer and as long as the root key 202 has not expired, the KRS can use the same root keys to derive fresh 203 keying material to protect the requested service. These kinds of key 204 requests and distributions are necessary because an EMSK cannot leave 205 the EAP server ([RFC5295]). Hence, any root key that is directly 206 derived from an EMSK can only be derived by the EAP server itself. 207 The EAP server then exports these keys to a server that can 208 distribute the keys to the KRS. In the remainder of this document, 209 the KDS consisting of the EAP server that derives the root keys 210 together with the AAA server that distributes these keys is denoted 211 EAP/AAA server. Root keys derived from EMSK child keys, such as a 212 DSUSRK, can be requested from the respective root key holder. Hence, 213 a KDS can be either the EAP/AAA server or a DSRK holder (DSR-KH), 214 whereas a KRS can be either a USRK holder (USR-KH), a DSR-KH or a 215 DSUSRK holder (DSUSR-KH). 217 The KRS needs to share an interface with the KDS to be able to send 218 all necessary input data to derive the requested key and to receive 219 the requested key. The provided data includes the Key Derivation 220 Function (KDF) that should be used to derive the requested key. The 221 KRS uses the received root key to derive further keying material in 222 order to secure its offered services. Every KDS is responsible for 223 storing and protecting the received root key as well as the 224 derivation and distribution of any child key derived from the root 225 key. An example of a key delivery architecture is illustrated in 226 Figure 1 showing the different types of KRS and their interfaces to 227 the KDS. 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | EAP/AAA server | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 / | | \ 233 / | | \ 234 / | | \ 235 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 236 | USR-KH1 | | USR-KH2 | | DSR-KH1 | | DSR-KH2 | 237 | HOKEY server| | XYZ server| |Domain 1 | | Domain 2| 238 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 239 / | 240 / | 241 / | 242 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 243 | DSUSR-KH | | DSUSR-KH2 | 244 | Domain 1 | | Domain 2 | 245 |Home domain | |Visited domain | 246 |HOKEY server | |HOKEY server | 247 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 249 Figure 1: Example Key Delivery Architecture for the Different KRS and 250 KDS 252 4. Key Distribution Exchange (KDE) 254 In this section, a generic mechanism for a key distribution exchange 255 (KDE) over AAA is described in which a root key (RK) is distributed 256 from a KDS to a KRS. It is required that the communication path 257 between the KDS and the KRS is protected by the use of an appropriate 258 AAA transport security mechanism (see Section 6 for security 259 requirements). Here, it is assumed that the KRS and the KDS are 260 separate entities, logically if not physically, and the delivery of 261 the requested RK is specified accordingly. 263 The key distribution exchange consists of one roundtrip, i.e. two 264 messages between the KRS and the KDS, as illustrated in Figure 2. 265 First, the KRS sends a KDE-Request carrying a Key Request Token 266 (KRT). As a response, the KDS sends a KDE-Response carrying a Key 267 Delivery Token (KDT). Both tokens are encapsulated in AAA messages. 268 The definition of the AAA attributes depends on the implemented AAA 269 protocol and is out of scope of this document. However, the security 270 requirements for AAA messages carrying KDE messages are discussed in 271 Section 6. The contents of KRT and KDT are defined in the following. 273 KRS KDS 274 -------- ------- 275 | | 276 | KDE-Request: AAA{KRT} | 277 |----------------------------------------->| 278 | KDE-Response: AAA{KDT} | 279 |<-----------------------------------------| 281 Figure 2: KDE Message Flow 283 KRT : (PID, KT, KL) 285 KRT carries the identifiers of the peer (PID), the key type (KT) 286 and the key label (KL). The following key types are defined: 0 287 (DSRK), 1 (USRK) and 2 (DSUSRK). See [RFC5295] for the 288 specification of key labels. 290 KDT : (KT, KL, RK, KN_RK, LT_RK) 292 KDT carries the root key (RK) to be distributed to the KRS, as 293 well as the key type (KT), the key label (KL), the key name 294 (KN_RK) and the lifetime of RK (LT_RK). The key lifetime of each 295 distributed key MUST NOT be greater than that of its parent key. 297 4.1. Context and Scope for Distributed Keys 299 The key context of each distributed key is determined by the sequence 300 of KTs in the key hierarchy. The key scope of each distributed key 301 is determined by the sequence of (PID, KT, KL)-tuples in the key 302 hierarchy and the identifier of the KRS. The KDF used to generate 303 the requested keys includes context and scope information, thus, 304 binding the key to the specific channel [RFC5295]. 306 4.2. Key Distribution Exchange Scenarios 308 Given the three types of KRS, there are three scenarios for the 309 distribution of the EMSK child keys. For all scenarios, the trigger 310 and mechanism for key delivery may involve a specific request from an 311 EAP peer and/or another intermediary (such as an authenticator). For 312 simplicity, it is assumed that USR-KHs reside in the same domain as 313 the EAP server. 315 Scenario 1: EAP/AAA server to USR-KH: In this scenario, the EAP/AAA 316 server delivers a USRK to a USR-KH. 318 Scenario 2: EAP/AAA server to DSR-KH: In this scenario, the EAP/AAA 319 server delivers a DSRK to a DSR-KH. 321 Scenario 3: DSR-KH to DSUSR-KH: In this scenario, a DSR-KH in a 322 specific domain delivers keying material to a DSUSR-KH in the same 323 domain. 325 The key distribution exchanges for Scenario 3 can be combined with 326 the key distribution exchanges for Scenario 2 into a single roundtrip 327 exchange as shown in Figure 3. Here, KDE-Request and KDE-Response 328 are messages for Scenarios 2, whereas KDE-Request' and KDE-Response' 329 are messages for Scenarios 3. 331 DSUSR-KH DSR-KH EAP/AAA Server 332 -------- ------ ------------ 333 | KDE-Request'(KRT') | KDE-Request(KRT) | 334 |------------------------>|-------------------------->| 335 | KDE-Response'(KDT') | KDE-Response(KDT) | 336 |<----------------------- |<--------------------------| 337 | | | 339 Figure 3: Combined Message Exchange 341 5. KDE used in the EAP Re-authentication Protocol (ERP) 343 This section describes how the presented KDE should be used to 344 request and deliver the root keys used for re-authentication in the 345 EAP Re-authentication Protocol (ERP) defined in [RFC5296]. ERP 346 supports two forms of bootstrapping, implicit as well as explicit 347 bootstrapping, and KDE is discussed for both cases in the remainder 348 of this section. 350 In implicit bootstrapping the local EAP Re-authentication (ER) server 351 requests the DSRK from the home AAA server during the initial EAP 352 exchange. Here, the local ER server acts as the KRS and the home AAA 353 server as the KDS. In this case, the local ER server requesting the 354 DSRK MUST include a KDE-Request message in the first EAP-Response 355 message from the peer. Here, an AAA User-Name attribute is used as 356 the PID. If the EAP exchange is successful, the home AAA server 357 includes a KDE-Response message in the AAA message that carries the 358 EAP-Success message. 360 Explicit bootstrapping is initiated by peers that do not know the 361 domain. Here, EAP-Initiate and EAP-Finish messages are exchanged 362 between the peer and the home AAA server, with the bootstrapping flag 363 in the EAP-Initiate message set. In this case, the local ER server 364 (acting as KRS) MUST include a KDE-Request message in the AAA message 365 that carries an EAP-Initiate message with the bootstrapping flag 366 turned on. Here, an AAA User-Name attribute is used as the PID. In 367 its response, the home AAA server (acting as KDS) MUST include a KDE- 368 Response message in the AAA message that carries the EAP-Finish 369 message with the bootstrapping flag set. 371 6. Security Considerations 373 This section provides security requirements and an analysis on 374 transporting EAP keying material using an AAA protocol. 376 6.1. Requirements on AAA Key Transport Protocols 378 Any KDE attribute that is exchanged as part of a KDE-Request or KDE- 379 Response message MUST be integrity-protected and replay-protected by 380 the underlying AAA protocol that is used to encapsulate the 381 attributes. Additionally, a secure key wrap algorithm MUST be used 382 by the AAA protocol to protect the RK in a KDE-Response message. 383 Other confidential information as part of the KDE messages (e.g. 384 identifiers if privacy is a requirement) SHOULD be encrypted by the 385 underlying AAA protocol. 387 When there is an intermediary, such as an AAA proxy, on the path 388 between the KRS and the KDS, there will be a series of hop-by-hop 389 security associations along the path. The use of hop-by-hop security 390 associations implies that the intermediary on each hop can access the 391 distributed keying material. Hence the use of hop-by-hop security 392 SHOULD be limited to an environment where an intermediary is trusted 393 not to abuse the distributed key material. If such a trusted AAA 394 infrastructure does not exist, other means must be applied at a 395 different layer to ensure the end-to-end security (i.e. between KRS 396 and KDS) of the exchanged KDE messages. The security requirements 397 for such a protocol are the same as previously outlined for AAA 398 protocols and MUST hold when encapsulated in AAA messages. 400 6.2. Distributing RK without Peer Consent 402 When a KDE-Request message is sent as a result of explicit ERP 403 bootstrapping [RFC5296], cryptographic verification of peer consent 404 on distributing a RK is provided by the integrity checksum of the 405 EAP-Initiate message with the bootstrapping flag turned on. 407 On the other hand, when a KDE-Request message is sent as a result of 408 implicit ERP bootstrapping [RFC5296], cryptographic verification of 409 peer consent on distributing a RK is not provided. A peer is not 410 involved in the process and, thus, not aware of a key delivery 411 requests for root keys derived from its established EAP keying 412 material. Hence, a peer has no control where keys derived from its 413 established EAP keying material are distributed to. A possible 414 consequence of this is that a KRS may request and obtain a RK from 415 the home server even if the peer does not support ERP. EAP-Initiate/ 416 Re-auth-Start messages send to the peer will be silently dropped by 417 the peer causing further waste of resources. 419 7. IANA consideration 421 This document defines a new namespace for maintaining Key Type used 422 to identify the type of the root key RK. The range of values 0 - 255 423 are for permanent, standard message types, allocated by IETF Review 424 [IANA]. This document defines the values 0 (DSRK), 1 (USRK) and 2 425 (DSUSRK). 427 8. Acknowledgements 429 The author would like to thank Dan Harkins, Chunqiang Li, Rafael 430 Marin Lopez and Charles Clancy for their valuable comments. 432 9. Contributors 434 The following people contributed to this document: Madjid Nakhjiri, 435 Kedar Gaonkar, Lakshminath Dondeti, Vidya Narayanan, and Glen Zorn. 437 10. References 439 10.1. Normative References 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, March 1997. 444 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 445 "Remote Authentication Dial In User Service (RADIUS)", 446 RFC 2865, June 2000. 448 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 449 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 451 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 452 Levkowetz, "Extensible Authentication Protocol (EAP)", 453 RFC 3748, June 2004. 455 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 456 "Specification for the Derivation of Root Keys from an 457 Extended Master Session Key (EMSK)", RFC 5295, 458 August 2008. 460 [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 461 authentication Protocol (ERP)", RFC 5296, August 2008. 463 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an 464 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 465 May 2008. 467 10.2. Informative references 469 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 470 Dial In User Service) Support For Extensible 471 Authentication Protocol (EAP)", RFC 3579, September 2003. 473 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 474 Authentication Protocol (EAP) Key Management Framework", 475 RFC 5247, August 2008. 477 [RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, 478 "Handover Key Management and Re-Authentication Problem 479 Statement", RFC 5169, March 2008. 481 Authors' Addresses 483 Katrin Hoeper (editor) 484 Motorola 485 1301 E Algonquin Road 486 Schaumburg, IL 60196 487 USA 489 Phone: +1 847 576 4714 490 Email: khoeper@motorola.com 492 Yoshihiro Ohba (editor) 493 Toshiba America Research, Inc. 494 1 Telcordia Drive 495 Piscataway, NJ 08854 496 USA 498 Phone: +1 732 699 5305 499 Email: yohba@tari.toshiba.com