idnits 2.17.1 draft-ietf-krb-wg-cross-problem-statement-05.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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 13, 2009) is 5302 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Sakane 3 Intended Status: Informational Ken'ichi Kamada 4 Expires: April 16, 2010 S. Zrelli 5 Yokogawa Electric Corp. 6 M. Ishiyama 7 Toshiba Corp. 8 October 13, 2009 10 Problem statement on the cross-realm operation of Kerberos 11 draft-ietf-krb-wg-cross-problem-statement-05.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft expires in April 16, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 The Kerberos protocol is today one of the most widely deployed 50 authentication protocols in the Internet. In order for a Kerberos 51 deployment to operate in a scalable manner, different Kerberos realms 52 must interoperate in such a way that cross-realm operations can be 53 performed efficiently and securely. 55 This document provides background information regarding large scale 56 Kerberos deployments in the industrial sector, with the aim of 57 identifying issues in the current Kerberos cross-realm authentication 58 model as defined in RFC4120. 60 As industrial automation is moving towards wider adoption of Internet 61 standards, the Kerberos authentication protocol represents one of the 62 best alternatives for ensuring the confidentiality and the integrity 63 of communications in control networks while meeting performance and 64 security requirements. 66 However, the use of Kerberos cross-realm operations in large scale 67 industrial systems may introduce issues that could cause performance 68 and reliability problems. This document describes some examples of 69 actual large scale industrial systems, and lists requirements and 70 restriction regarding authentication operations in such environments. 72 The current document also identifies a number of requirements derived 73 from the industrial automation field. Although they are found in the 74 field of industrial automation, these requirements are general enough 75 and are applicable to the problem of Kerberos cross-realm operations. 77 These requirements need to be satisfied by proposed Kerberos cross- 78 realm frameworks or architectures, as well as specific solutions that 79 implement those frameworks or architectures. 81 Conventions used in this document 83 The reader is assumed to be familiar with the terms and concepts 84 described in the Kerberos Version 5 [RFC4120]. 86 Table of Contents 88 1. Introduction ................................................. 4 89 2. Kerberos System .............................................. 4 90 2.1. Kerberos basic operation ................................ 4 91 2.2. Cross-realm operation ................................... 5 92 3. Applying Cross-Realm Kerberos in Complex Environments ........ 6 93 4. Requirements ................................................. 7 94 5. Issues ....................................................... 9 95 5.1. Unreliability of authentication chain ................... 9 96 5.2. Possibility of MITM in the indirect trust model ......... 9 97 5.3. Scalability of the direct trust model ................... 10 98 5.4. Exposure to DoS Attacks ................................. 10 99 5.5. Client's performance .................................... 10 100 5.6. Kerberos Pre-authentication problem in roaming scenarios 11 101 6. Implementation considerations ................................ 11 102 7. IANA Considerations .......................................... 12 103 8. Security Considerations ...................................... 12 104 9. Acknowledgements ............................................. 12 105 10. References ................................................... 12 106 10.1. Normative References ................................... 12 107 10.2. Informative References ................................. 12 108 Authors' Addresses ............................................... 13 110 1. Introduction 112 Kerberos Version 5 is a widely deployed mechanism that enables a 113 server to authenticate a client before granting it access to a 114 certain service. Each client belongs to a managed domain called 115 realm. Kerberos supports authentication when a client and a server 116 belong to different realms. This is called cross-realm 117 authentication. 119 There exist several ways for using Kerberos in large scale 120 distributed systems. Such infrastructures are typically split into 121 several managed domains for geographical reasons, and to implement 122 different management policies. In order to ensure smooth network 123 operations in such systems, a common authentication mechanism for the 124 different managed domains is required. When using the Kerberos 125 cross-realm operation in large scale distributed systems some issues 126 arise. 128 This document briefly describes the Kerberos Version 5 system and its 129 cross-realm operation mode. Then it describes two case-study systems 130 that Kerberos could be applied to, and describes seven requirements 131 in those systems in terms both of management and operations that 132 outline various constraints which Kerberos operations might be 133 subjected to. Finally, it lists six issues related to Kerberos 134 cross-realm operations when applied to those systems. 136 Note that this document might not describe all issues related to 137 Kerberos cross-realm operations. New issues might be found in the 138 future. It also does not propose any solution to solve the issues. 139 Furthermore, publication of this document does not mean that each of 140 the issues have to be solved by the IETF members. Detailed analysis 141 of the issues, problem definitions and exploration of possible 142 solutions may be carried out as separate work items. 144 This document is assumed that the readers are familiar with the terms 145 and concepts described in the Kerberos Version 5 [RFC4120]. 147 2. Kerberos System 149 2.1. Kerberos basic operation 151 Kerberos [RFC4120] is a widely deployed authentication system. The 152 authentication process in Kerberos involves principals and a Key 153 Distribution Center (KDC). The principals can be users or services. 154 Each KDC maintains a database of principals and shares a secret key 155 with each registered principal. 157 The authentication process allows a user to acquire the needed 158 credentials from the KDC. These credentials allow services to 159 authenticate the users before granting them access to the resources. 160 An important part of the credentials are called Tickets. There are 161 two kinds of tickets: Ticket Granting Ticket (TGT) and Service 162 Ticket. The TGT is obtained periodically from the KDC and has a 163 limited lifetime after which it expires and the user must renew it. 164 The TGT is used to obtain the other kind of tickets; Service Tickets. 165 The user obtains a TGT from the Authentication Service (AS), a 166 logical component of the KDC. The process of obtaining a TGT is 167 referred to as 'AS exchange'. When a request for a TGT is issued by 168 the user, the AS responds by sending a reply packet containing the 169 credentials which consists of the TGT along with a random key called 170 'TGS Session Key'. The TGT contains a set of information encrypted 171 using a secret key associated with a special service referred to as 172 TGS (Ticket Granting Service). The TGS session key is encrypted 173 using the user's key so that the user can obtain the TGS session key 174 only if she knows the secret key she shares with the KDC. The TGT 175 then is used to obtain a Service Tickets from the Ticket Granting 176 Service (TGS)- the second component of the KDC. The process of 177 obtaining service tickets is referred to as 'TGS exchange'. The 178 request for a service ticket consists on a packet containing a TGT 179 and an 'Authenticator'. The Authenticator is encrypted using the TGS 180 session key and contains the identity of the user as well as time 181 stamps (for protection against replay attacks). After decrypting the 182 TGT received from the user, the TGS extracts the TGS session key. 183 Using that session key, it decrypts the Authenticator and 184 authenticates the user. Then, the TGS issues the credentials 185 requested by the user. These credentials consist of a service ticket 186 and a session key that will be used to authenticate the user to the 187 desired application service. 189 2.2. Cross-realm operation 191 The Kerberos protocol provides cross-realm authentication 192 capabilities. This allows users to obtain service tickets to access 193 services in foreign realms. In order to access such services, the 194 users first contact their home KDC asking for a TGT that will be used 195 with the TGS of the foreign realm. If there is a direct trust 196 relationship between the home realm and the foreign realm 197 (practically materialized in shared inter-realm keys), the home KDC 198 delivers the requested TGT. 200 However, if the home realm does not share inter-realm keys with the 201 foreign realm, we are in a so-called indirect trust model situation. 202 In this situation, the home KDC will provide a TGT that can be used 203 with an intermediary foreign realm that is likely to be sharing 204 inter-realm keys with the target realm. The client can use this 205 'intermediary TGT' to communicate with the intermediary KDC which 206 will iterate the actions taken by the home KDC; If the intermediary 207 KDC does not share inter-realm keys with the target foreign realm it 208 will point the user to another intermediary KDC (just as in the first 209 exchange between the user and its home KDC). However, in the other 210 case (when it shares inter-realm keys with the target realm), the 211 intermediary KDC will issue a TGT that can be used with the KDC of 212 the target realm. After obtaining a TGT for the desired foreign 213 realm, the client uses it to obtain service tickets from the TGS of 214 the foreign realm. Finally, the user accesses the service using the 215 service ticket. 217 When the realms belong to the same institution, a chain of trust can 218 be automatically determined by the client or the KDC by following the 219 DNS domain hierarchy and assuming that a parent domain shares keys 220 with all its child sub-domains. However, since this assumption is 221 not always true, in many situations, the trust path might have to be 222 specified manually. Since the Kerberos cross-realm operations with 223 indirect inter-realm trust model rely on intermediary realms, the 224 success of the cross-realm operation completely depends on the realms 225 that are part of the authentication path. 227 3. Applying Cross-Realm Kerberos in Complex Environments 229 In order to help understanding requirements and restrictions for 230 cross-realm authentication operations, this section describes the 231 scale and operations of two actual systems that could be supported by 232 cross-realm Kerberos. The two systems would be most naturally be 233 implemented using different trust models, which will imply different 234 requirements for cross-realm Kerberos. 236 Hereafter, we will consider an actual petrochemical company 237 [SHELLCHEM], and overview two examples among its plants. 238 Petrochemical companies produce bulk petrochemicals and deliver them 239 to large industrial customers. The company in consideration 240 possesses 43 plants all over the world managed by operation sites in 241 35 countries. This section shows two examples of these plants. 243 The first example is a plant deploying a centralized system [CSPC]. 244 CSPC is operated by a joint enterprise of two companies. This system 245 is one of the largest systems of this company in the world. It is 246 located in an area of 3.4 square kilometers in the north coast of 247 Daya Bay, Guangdong, in southeast China. 3,000 network segments are 248 deployed in the system and 16,000 control devices are connected to 249 local area networks. These devices belong to 9 different subsystems. 250 A control device can have many control and monitoring points. In the 251 plant considered in this example, there are 200,000 control points in 252 all. They are controlled by 3 different control centers. 254 Another example is a distributed system [NAM]. The NAM (Nederlandse 255 Aardolie Maatschappij) is operated by a partnership company of two 256 enterprises that represent the oil company. This system is composed 257 of some plants that are geographically distributed within the range 258 of 863 square kilometers in the northern part of Netherlands. 26 259 plants, each called "cluster", are scattered in the area. They are 260 connected to each other by a private ATM WAN. Each cluster has 261 approximately 500-1,000 control devices. These devices are managed 262 by local control center in each cluster. In the entire system of the 263 NAM, there are one million control points. 265 In the both examples, the end devices are basically connected to a 266 local network by a twisted pair cable, with a low band-width of 32 267 kbps. End devices use a low clock CPU, for example the H8 [RNSS-H8] 268 and M16C [RNSS-M16C]. Furthermore, to reduce power consumption (due 269 explosion-proof requirements), the clock on the CPU may be lowered. 271 A device on the network collects data from other devices monitoring 272 the condition of the system. This date is then used to make 273 decisions on how to control other devices with instructions 274 transmitted over the network. If it takes time for data to travel 275 through the network, normal operations can not be ensured. The 276 travel time of data from a device to another device must be within 1 277 second at most. 279 Some parts of the operations such as control, maintenance, and 280 environmental monitoring can be consigned to an external 281 organization. Also, agents may be consigned to walk around the plant 282 and collect information about the plant operations, or watch the 283 plant from a remote site. 285 4. Requirements 287 This section provides a list of requirements derived from the 288 industrial automation use-case. The requirements are written in a 289 generic fashion, and are addressed towards frameworks and 290 architectures that underlie Kerberos cross-realm operations. The aim 291 of these requirements is to provide some foundational guidelines to 292 the future developments of cross-realm framework or architecture for 293 Kerberos. 295 R-1, R-2, R-3 and R-4 are related to the management of the divided 296 system. R-5, R-6 and R-7 are related to the restriction to such 297 large scale industrial network. 299 R-1 For organizational reasons and scalability needs, a management 300 domain typically must be partitioned into two or more sub- 301 domains of management. Therefore, any architecture and 302 implementation solution to the Kerberos cross-realm problem must 303 (i) support the case of cross-realm operations across multiple 304 management domains and (ii) support delegation of management 305 authority from one domain to another management domain. This 306 must be performed without any decrease in the security level or 307 quality of those cross-realm operations and must not expose 308 Kerberos entities to new types of attacks. 310 R-2 Any architecture and implementation solution to the Kerberos 311 cross-realm problem must support the co-existence of multiple 312 independent management domains on the same network. 313 Furthermore, it must allow organizations (corresponding to 314 different management domains) to delegate the management of a 315 part of or the totality of their system at any one time. 317 R-3 Any architecture and implementation solution to the Kerberos 318 cross-realm problem must allow the use-case in which one device 319 operationally controls another device, but each belongs to 320 different management domains respectively. 322 R-4 Any architecture and implementation solution to the Kerberos 323 cross-realm problem must address the fundamental deployment use- 324 case in which the management domain traverses geographic 325 boundaries and network topological boundaries. In particular, 326 it must address the case where devices are geographically (or 327 topologically) remote, even though they belong to the same 328 management domain. 330 R-5 Any architecture and implementation solution to the Kerberos 331 cross-realm problem must be aimed at reducing operational and 332 management costs as much as possible. 334 R-6 Any architecture and implementation solution to the Kerberos 335 cross-realm problem must address the (limited) processing 336 capabilities of devices, and implementations of solutions must 337 be considered to aim at limiting or suppressing power 338 consumption of such devices. 340 R-7 Any architecture and implementation solution to the Kerberos 341 cross-realm problem must address the possibility of limited 342 availability of communications bandwidth between devices within 343 one domain, and also across domains. 345 5. Issues 347 This section lists issues in Kerberos cross-realm operations when 348 used in large scale systems such as the ones described in section 3, 349 and taking in consideration the requirements described in section 4. 351 5.1. Unreliability of authentication chain 353 When the trust relationship between realms follows chain or 354 hierarchical model, the cross-realm authentication operations are no 355 dependable since they strongly depend on intermediary realms that 356 might not be under the same authority. If any of the realms in the 357 authentication path is not available, then the principals of the end 358 realms can not perform cross-realm operations. 360 The end-point realms do not have full control and responsibility of 361 the success of the cross-realm operations even if their own 362 respective KDCs are fully functional. Dependability of a system 363 decreases if the system relies on uncontrolled components. End-point 364 realms have no way of knowing the authentication result occurring 365 within intermediary realms. 367 Satisfying requirements R-1 and R-2 will eliminate (or considerably 368 diminish) this issue of the unreliability of the authentication 369 chain. 371 5.2. Possibility of MITM in the indirect trust model 373 Every KDC in the authentication path knows the shared secret between 374 the client and the remaining KDCs in the authentication path. This 375 allows a malicious KDC to perform MITM attacks on communications 376 between the client and any KDC in the remaining authentication chain. 377 A malicious KDC also may learn the service session key that is used 378 to protect the communication between the client and the actual 379 application service. It can then use this key to perform a MITM 380 attack. 382 In [SPECCROSS], the authors have analyzed the cross-realm operations 383 in Kerberos and provided formal proof of the issue discussed in this 384 section. 386 Satisfying requirements R-1 and R-2 will eliminate (or considerably 387 diminish) this issue of MITM attacks by intermediate KDCs in the 388 indirect trust model. 390 5.3. Scalability of the direct trust model 392 In the direct trust relationship model, the realms involved in the 393 cross-realm operations share keys and their respective TGS principals 394 are registered in each other's KDC. Each realm must maintain keys 395 with all foreign realms that it interacts with. This can become a 396 cumbersome task and may increase maintenance costs when the number of 397 realms increases. 399 Satisfying requirements R-1, R-2 and R-5 will eliminate (or 400 considerably diminish) this issue of scalability of the indirect 401 trust model. 403 5.4. Exposure to DoS Attacks 405 One of the assumptions made when allowing the cross-realm operation 406 in Kerberos is that users can communicate with KDCs located in remote 407 realms. This practice introduces security threats because KDCs are 408 open to the public network. Administrators may think of restricting 409 the access to the KDC to the trusted realms only. However, this 410 approach is not scalable and does not really protect the KDC. 411 Indeed, when the remote realms have several IP prefixes (e.g. control 412 centers or outsourcing companies, located world wide), then the 413 administrator of the local KDC must collect the list of prefixes that 414 belong to these organization. The filtering rules must then 415 explicitly allow the incoming traffic from any host that belongs to 416 one of these prefixes. This makes the administrator's tasks more 417 complicated and prone to human errors. And also, the maintenance 418 cost increases. On the other hand, when a range of external IP 419 addresses are allowed to communicate with the KDC then the risk of 420 becoming target to attacks from remote malicious users increases. 422 Satisfying requirements R-1, R-3, R-4 and R-5 will eliminate (or 423 considerably diminish) this issue of exposure to DoS attacks. 425 5.5. Client's performance 427 In Kerberos cross-realm operations, clients have to perform TGS 428 exchanges with all the KDCs in the trust path, including the home KDC 429 and the target KDC. A TGS exchange requires cryptographic operations 430 and may consume a large amount of processing time especially when the 431 client has limited computational capabilities. As a result, the 432 overhead of Kerberos cross-realm exchanges may grows into 433 unacceptable delays. 435 We ported the MIT Kerberos library (version 1.2.4), implemented a 436 Kerberos client on our original board with H8 (16-bit, 20MHz), and 437 measured the process time of each Kerberos message [KRBIMPL]. It 438 takes 195 milliseconds to perform a TGS exchange with the on-board 439 H/W crypto engine. Indeed, this result seems reasonable to the 440 requirement of the response time for the control network. However, 441 we did not modify the clock speed of the H8 during our measurement. 442 The processing time must be slower in a actual environment because H8 443 is used with lowered clock speed in such system. With such devices, 444 the delays can grow to unacceptable delays when the number of 445 intermediary realms increases. 447 Satisfying requirements R-1, R-2, R-6 and R-7 will eliminate (or 448 considerably diminish) this issue relating to the client's 449 performance. 451 5.6. Kerberos Pre-authentication problem in roaming scenarios 453 In roaming scenarios, the client needs to contact her home KDC to 454 obtain a cross-realm TGT for the local (or visited) realm. However, 455 the policy of the network access providers or the gateway in the 456 local network usually does not allow clients to communicate with 457 hosts in the Internet unless they provide valid authentication 458 credentials. In this manner, the client encounters a chicken-and-egg 459 problem where two resources are interdependent; the Internet 460 connection is needed to contact the home KDC and for obtaining 461 credentials, and on the other hand, the Internet connection is only 462 granted for clients who have valid credentials. As a result, the 463 Kerberos protocol can not be used as it is for authenticating roaming 464 clients requesting network access. 466 Satisfying requirements R-3 and R-4 will eliminate (or considerably 467 diminish) this roaming-related issue pertaining to Kerberos per- 468 authentication. 470 6. Implementation considerations 472 This document describes issues of the cross-realm operation. There 473 are important matters to be considered, when designing and 474 implementing solutions for these issues. Solution must not introduce 475 new problems. Any solution should use existing components or 476 protocols as much as possible, and it should avoid introducing 477 definitions of new components. It should not require new changes to 478 existing deployed clients, and it should not influence the client 479 code-base as much as possible. Because a KDC is a significant server 480 in an information system based on Kerberos. New burden on the KDC 481 should be minimal. Solutions must take these tradeoffs and the 482 requirements into consideration. On the other hand, solutions are 483 not required to solve all the issues listed in this document at once. 485 7. IANA Considerations 487 This document makes no request of IANA. 489 8. Security Considerations 491 This document clarifies the issues of the cross-realm operation of 492 the Kerberos V system, which include security issues to be 493 considered. See Section 5.1, 5.2, 5.3 and 5.4 for further details. 495 9. Acknowledgements 497 The authors are grateful to Nobuo Okabe, Kazunori Miyazawa, and 498 Atsushi Inoue. They gave us lots of comments and suggestions to this 499 document from the early stage. Nicolas Williams, Chaskiel Grundman 500 and Love Hornquist Astrand gave valuable suggestions and corrections. 501 Thomas Hardjono devoted much work and helped to improve this 502 document. Finally, the authors thank to Jeffrey Hutzelman. He gave 503 us a lot of suggestions for completion of this document. 505 10. References 507 10.1. Normative References 509 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 510 Kerberos Network Authentication Service (V5)", RFC 511 4120, July 2005. 513 10.2. Informative References 515 [CSPC] http://www.shellchemicals.com/news/1,1098,72-news_id= 516 531,00.html 518 [KRBIMPL] "A Prototype of a Secure Autonomous Bootstrap Mechanism 519 for Control Networks", Nobuo Okabe, Shoichi Sakane, 520 Masahiro Ishiyama, Atsushi Inoue and Hiroshi Esaki, 521 SAINT, pp. 56-62, IEEE Computer Society, 2006. 523 [NAM] http://www.nam.nl/ 525 [RNSS-H8] http://www.renesas.com/fmwk.jsp?cnt=h8_family_landing. 526 jsp&fp=/products/mpumcu/h8_family/ 528 [RNSS-M16C] http://www.renesas.com/fmwk.jsp?cnt=m16c_family_landi 529 ng.jsp&fp=/products/mpumcu/m16c_family/ 531 [SHELLCHEM] http://www.shellchemicals.com/home/1,1098,-1,00.html 533 [SPECCROSS] I. Cervesato and A. Jaggard and A. Scedrov and C. 534 Walstad, "Specifying Kerberos 5 Cross-Realm 535 Authentication", Fifth Workshop on Issues in the Theory 536 of Security, Jan 2005. 538 Authors' Addresses 540 Shoichi Sakane 541 Yokogawa Electric Corporation 542 2-9-32 Nakacho, Musashino-shi, 543 Tokyo 180-8750 Japan 544 E-mail: Shouichi.Sakane@jp.yokogawa.com 546 Ken'ichi Kamada 547 Yokogawa Electric Corporation 548 2-9-32 Nakacho, Musashino-shi, 549 Tokyo 180-8750 Japan 550 E-mail: Ken-ichi.Kamada@jp.yokogawa.com 552 Saber Zrelli 553 Yokogawa Electric Corporation 554 2-9-32 Nakacho, Musashino-shi, 555 Tokyo 180-8750 Japan 556 E-mail: Saber.Zrelli@jp.yokogawa.com 558 Masahiro Ishiyama 559 Toshiba Corporation 560 1, komukai-toshiba-cho, Saiwai-ku, 561 Kawasaki 212-8582 Japan 562 E-mail: masahiro@isl.rdc.toshiba.co.jp