idnits 2.17.1 draft-ietf-krb-wg-cross-problem-statement-06.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 (January 5, 2010) is 5225 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: July 9, 2010 S. Zrelli 5 Yokogawa Electric Corp. 6 M. Ishiyama 7 Toshiba Corp. 8 January 5, 2010 10 Problem statement on the cross-realm operation of Kerberos 11 draft-ietf-krb-wg-cross-problem-statement-06.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 July 9, 2010. 36 Copyright Notice 38 Copyright (c) 2010 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 Conventions used in this document 79 The reader is assumed to be familiar with the terms and concepts 80 described in the Kerberos Version 5 [RFC4120]. 82 Table of Contents 84 1. Introduction ................................................. 4 85 2. Kerberos System .............................................. 4 86 2.1. Kerberos basic operation ................................ 4 87 2.2. Cross-realm operation ................................... 5 88 3. Applying Cross-Realm Kerberos in Complex Environments ........ 6 89 4. Requirements ................................................. 7 90 5. Issues ....................................................... 9 91 5.1. Unreliability of authentication chain ................... 9 92 5.2. Possibility of MITM in the indirect trust model ......... 9 93 5.3. Scalability of the direct trust model ................... 10 94 5.4. Exposure to DoS Attacks ................................. 10 95 5.5. Client's performance .................................... 10 96 5.6. Kerberos Pre-authentication problem in roaming scenarios 11 97 6. Implementation considerations ................................ 11 98 7. IANA Considerations .......................................... 12 99 8. Security Considerations ...................................... 12 100 9. Acknowledgements ............................................. 12 101 10. References ................................................... 12 102 10.1. Normative References ................................... 12 103 10.2. Informative References ................................. 12 104 Authors' Addresses ............................................... 13 106 1. Introduction 108 Kerberos Version 5 is a widely deployed mechanism that enables a 109 server to authenticate a client before granting it access to a 110 certain service. Each client belongs to a managed domain called 111 realm. Kerberos supports authentication when a client and a server 112 belong to different realms. This is called cross-realm 113 authentication. 115 There exist several ways for using Kerberos in large scale 116 distributed systems. Such infrastructures are typically split into 117 several managed domains for geographical reasons, and to implement 118 different management policies. In order to ensure smooth network 119 operations in such systems, a common authentication mechanism for the 120 different managed domains is required. When using the Kerberos 121 cross-realm operation in large scale distributed systems some issues 122 arise. 124 This document briefly describes the Kerberos Version 5 system and its 125 cross-realm operation mode. Then it describes two case-study systems 126 that Kerberos could be applied to, and describes seven requirements 127 in those systems in terms both of management and operations that 128 outline various constraints which Kerberos operations might be 129 subjected to. Finally, it lists six issues related to Kerberos 130 cross-realm operations when applied to those systems. 132 Note that this document might not describe all issues related to 133 Kerberos cross-realm operations. New issues might be found in the 134 future. It also does not propose any solution to solve the issues. 135 Furthermore, publication of this document does not mean that each of 136 the issues have to be solved by the IETF members. Detailed analysis 137 of the issues, problem definitions and exploration of possible 138 solutions may be carried out as separate work items. 140 This document is assumed that the readers are familiar with the terms 141 and concepts described in the Kerberos Version 5 [RFC4120]. 143 2. Kerberos System 145 2.1. Kerberos basic operation 147 Kerberos [RFC4120] is a widely deployed authentication system. The 148 authentication process in Kerberos involves principals and a Key 149 Distribution Center (KDC). The principals can be users or services. 150 Each KDC maintains a database of principals and shares a secret key 151 with each registered principal. 153 The authentication process allows a user to acquire the needed 154 credentials from the KDC. These credentials allow services to 155 authenticate the users before granting them access to the resources. 156 An important part of the credentials are called Tickets. There are 157 two kinds of tickets: Ticket Granting Ticket (TGT) and Service 158 Ticket. The TGT is obtained periodically from the KDC and has a 159 limited lifetime after which it expires and the user must renew it. 160 The TGT is used to obtain the other kind of tickets; Service Tickets. 161 The user obtains a TGT from the Authentication Service (AS), a 162 logical component of the KDC. The process of obtaining a TGT is 163 referred to as 'AS exchange'. When a request for a TGT is issued by 164 the user, the AS responds by sending a reply packet containing the 165 credentials which consists of the TGT along with a random key called 166 'TGS Session Key'. The TGT contains a set of information encrypted 167 using a secret key associated with a special service referred to as 168 TGS (Ticket Granting Service). The TGS session key is encrypted 169 using the user's key so that the user can obtain the TGS session key 170 only if she knows the secret key she shares with the KDC. The TGT 171 then is used to obtain a Service Tickets from the Ticket Granting 172 Service (TGS)- the second component of the KDC. The process of 173 obtaining service tickets is referred to as 'TGS exchange'. The 174 request for a service ticket consists of a packet containing a TGT 175 and an 'Authenticator'. The Authenticator is encrypted using the TGS 176 session key and contains the identity of the user as well as time 177 stamps (for protection against replay attacks). After decrypting the 178 TGT received from the user, the TGS extracts the TGS session key. 179 Using that session key, it decrypts the Authenticator and 180 authenticates the user. Then, the TGS issues the credentials 181 requested by the user. These credentials consist of a service ticket 182 and a session key that will be used to authenticate the user to the 183 desired application service. 185 2.2. Cross-realm operation 187 The Kerberos protocol provides cross-realm authentication 188 capabilities. This allows users to obtain service tickets to access 189 services in foreign realms. In order to access such services, the 190 users first contact their home KDC asking for a TGT that will be used 191 with the TGS of the foreign realm. If there is a direct trust 192 relationship between the home realm and the foreign realm 193 (practically materialized in shared inter-realm keys), the home KDC 194 delivers the requested TGT. 196 However, if the home realm does not share inter-realm keys with the 197 foreign realm, we are in a so-called indirect trust model situation. 198 In this situation, the home KDC will provide a TGT that can be used 199 with an intermediary foreign realm that is likely to be sharing 200 inter-realm keys with the target realm. The client can use this 201 'intermediary TGT' to communicate with the intermediary KDC which 202 will iterate the actions taken by the home KDC; If the intermediary 203 KDC does not share inter-realm keys with the target foreign realm it 204 will point the user to another intermediary KDC (just as in the first 205 exchange between the user and its home KDC). However, in the other 206 case (when it shares inter-realm keys with the target realm), the 207 intermediary KDC will issue a TGT that can be used with the KDC of 208 the target realm. After obtaining a TGT for the desired foreign 209 realm, the client uses it to obtain service tickets from the TGS of 210 the foreign realm. Finally, the user accesses the service using the 211 service ticket. 213 When the realms belong to the same institution, a chain of trust can 214 be automatically determined by the client or the KDC by following the 215 DNS domain hierarchy and assuming that a parent domain shares keys 216 with all its child sub-domains. However, since this assumption is 217 not always true, in many situations, the trust path might have to be 218 specified manually. Since the Kerberos cross-realm operations with 219 indirect inter-realm trust model rely on intermediary realms, the 220 success of the cross-realm operation completely depends on the realms 221 that are part of the authentication path. 223 3. Applying Cross-Realm Kerberos in Complex Environments 225 In order to help understanding requirements and restrictions for 226 cross-realm authentication operations, this section describes the 227 scale and operations of two actual systems that could be supported by 228 cross-realm Kerberos. The two systems would be most naturally be 229 implemented using different trust models, which will imply different 230 requirements for cross-realm Kerberos. 232 Hereafter, we will consider an actual petrochemical company 233 [SHELLCHEM], and overview two examples among its plants. 234 Petrochemical companies produce bulk petrochemicals and deliver them 235 to large industrial customers. The company in consideration 236 possesses 43 plants all over the world managed by operation sites in 237 35 countries. This section shows two examples of these plants. 239 The first example is a plant deploying a centralized system [CSPC]. 240 CSPC is operated by a joint enterprise of two companies. This system 241 is one of the largest systems of this company in the world. It is 242 located in an area of 3.4 square kilometers in the north coast of 243 Daya Bay, Guangdong, in southeast China. 3,000 network segments are 244 deployed in the system and 16,000 control devices are connected to 245 local area networks. These devices belong to 9 different subsystems. 246 A control device can have many control and monitoring points. In the 247 plant considered in this example, there are 200,000 control points in 248 all. They are controlled by 3 different control centers. 250 Another example is a distributed system [NAM]. The NAM (Nederlandse 251 Aardolie Maatschappij) is operated by a partnership company of two 252 enterprises that represent the oil company. This system is composed 253 of some plants that are geographically distributed within the range 254 of 863 square kilometers in the northern part of Netherlands. 26 255 plants, each one called "cluster", are scattered in the area. They 256 are connected to each other by a private ATM WAN. Each cluster has 257 approximately 500-1,000 control devices. These devices are managed 258 by local control center in each cluster. In the entire system of the 259 NAM, there are one million control points. 261 In the both examples, the end devices are basically connected to a 262 local network by a twisted pair cable, with a low band-width of 32 263 kbps. End devices use a low clock CPU, for example the H8 [RNSS-H8] 264 and M16C [RNSS-M16C]. Furthermore, to reduce power consumption, the 265 clock on the CPU may be lowered. This adjustment restricts the 266 amount of total energy in the device, thereby reducing the risk of 267 explosions. 269 A device on the network collects data from other devices monitoring 270 the condition of the system. This date is then used to make 271 decisions on how to control other devices with instructions 272 transmitted over the network. If it takes time for data to travel 273 through the network, normal operations can not be ensured. The 274 travel time of data from a device to another device in the both 275 examples must be within 1 second at most. Other control system 276 applications may have shorter or longer timescales. 278 Some parts of the operations such as control, maintenance, and 279 environmental monitoring can be consigned to an external 280 organization. Also, agents may be consigned to walk around the plant 281 and collect information about the plant operations, or watch the 282 plant from a remote site. 284 4. Requirements 286 This section provides a list of requirements derived from the 287 industrial automation use-case. The requirements are written in a 288 generic fashion, and are addressed towards frameworks and 289 architectures that underlie Kerberos cross-realm operations. The aim 290 of these requirements is to provide some foundational guidelines to 291 the future developments of cross-realm framework or architecture for 292 Kerberos. 294 R-1, R-2, R-3 and R-4 are related to the management of the divided 295 system. R-5, R-6 and R-7 are related to the restriction to such 296 large scale industrial network. 298 R-1 For organizational reasons and scalability needs, a management 299 domain typically must be partitioned into two or more sub- 300 domains of management. Therefore, any architecture and 301 implementation solution to the Kerberos cross-realm problem must 302 (i) support the case of cross-realm operations across multiple 303 management domains and (ii) support delegation of management 304 authority from one domain to another management domain. This 305 must be performed without any decrease in the security level or 306 quality of those cross-realm operations and must not expose 307 Kerberos entities to new types of attacks. 309 R-2 Any architecture and implementation solution to the Kerberos 310 cross-realm problem must support the co-existence of multiple 311 independent management domains on the same network. 312 Furthermore, it must allow organizations (corresponding to 313 different management domains) to delegate the management of a 314 part of or the totality of their system at any one time. 316 R-3 Any architecture and implementation solution to the Kerberos 317 cross-realm problem must allow the use-case in which one device 318 operationally controls another device, but each belongs to 319 different management domains respectively. 321 R-4 Any architecture and implementation solution to the Kerberos 322 cross-realm problem must address the fundamental deployment use- 323 case in which the management domain traverses geographic 324 boundaries and network topological boundaries. In particular, 325 it must address the case where devices are geographically (or 326 topologically) remote, even though they belong to the same 327 management domain. 329 R-5 Any architecture and implementation solution to the Kerberos 330 cross-realm problem must be aimed at reducing operational and 331 management costs as much as possible. 333 R-6 Any architecture and implementation solution to the Kerberos 334 cross-realm problem must address the (limited) processing 335 capabilities of devices, and implementations of solutions must 336 be considered to aim at limiting or suppressing power 337 consumption of such devices. 339 R-7 Any architecture and implementation solution to the Kerberos 340 cross-realm problem must address the possibility of limited 341 availability of communications bandwidth between devices within 342 one domain, and also across domains. 344 5. Issues 346 This section lists issues in Kerberos cross-realm operations when 347 used in large scale systems such as the ones described in section 3, 348 and taking in consideration the requirements described in section 4. 350 5.1. Unreliability of authentication chain 352 When the trust relationship between realms follows chain or 353 hierarchical model, the cross-realm authentication operations are no 354 dependable since they strongly depend on intermediary realms that 355 might not be under the same authority. If any of the realms in the 356 authentication path is not available, then the principals of the end 357 realms can not perform cross-realm operations. 359 The end-point realms do not have full control and responsibility of 360 the success of the cross-realm operations even if their own 361 respective KDCs are fully functional. Dependability of a system 362 decreases if the system relies on uncontrolled components. End-point 363 realms have no way of knowing the authentication result occurring 364 within intermediary realms. 366 Satisfying requirements R-1 and R-2 will eliminate (or considerably 367 diminish) this issue of the unreliability of the authentication 368 chain. 370 5.2. Possibility of MITM in the indirect trust model 372 Every KDC in the authentication path knows the shared secret between 373 the client and the remaining KDCs in the authentication path. This 374 allows a malicious KDC to perform MITM attacks on communications 375 between the client and any KDC in the remaining authentication chain. 376 A malicious KDC also may learn the service session key that is used 377 to protect the communication between the client and the actual 378 application service. It can then use this key to perform a MITM 379 attack. 381 In [SPECCROSS], the authors have analyzed the cross-realm operations 382 in Kerberos and provided formal proof of the issue discussed in this 383 section. 385 Satisfying requirements R-1 and R-2 will eliminate (or considerably 386 diminish) this issue of MITM attacks by intermediate KDCs in the 387 indirect trust model. 389 5.3. Scalability of the direct trust model 391 In the direct trust relationship model, the realms involved in the 392 cross-realm operations share keys and their respective TGS principals 393 are registered in each other's KDC. Each realm must maintain keys 394 with all foreign realms that it interacts with. This can become a 395 cumbersome task and may increase maintenance costs when the number of 396 realms increases. 398 Satisfying requirements R-1, R-2 and R-5 will eliminate (or 399 considerably diminish) this issue of scalability of the indirect 400 trust model. 402 5.4. Exposure to DoS Attacks 404 One of the assumptions made when allowing the cross-realm operation 405 in Kerberos is that users can communicate with KDCs located in remote 406 realms. This practice introduces security threats because KDCs are 407 open to the public network. Administrators may think of restricting 408 the access to the KDC to the trusted realms only. However, this 409 approach is not scalable and does not really protect the KDC. 410 Indeed, when the remote realms have several IP prefixes (e.g. control 411 centers or outsourcing companies, located world wide), then the 412 administrator of the local KDC must collect the list of prefixes that 413 belong to these organization. The filtering rules must then 414 explicitly allow the incoming traffic from any host that belongs to 415 one of these prefixes. This makes the administrator's tasks more 416 complicated and prone to human errors. And also, the maintenance 417 cost increases. On the other hand, when a range of external IP 418 addresses are allowed to communicate with the KDC then the risk of 419 becoming target to attacks from remote malicious users increases. 421 Satisfying requirements R-1, R-3, R-4 and R-5 will eliminate (or 422 considerably diminish) this issue of exposure to DoS attacks. 424 5.5. Client's performance 426 In Kerberos cross-realm operations, clients have to perform TGS 427 exchanges with all the KDCs in the trust path, including the home KDC 428 and the target KDC. A TGS exchange requires cryptographic operations 429 and may consume a large amount of processing time especially when the 430 client has limited computational capabilities. As a result, the 431 overhead of Kerberos cross-realm exchanges may grows into 432 unacceptable delays. 434 We ported the MIT Kerberos library (version 1.2.4), implemented a 435 Kerberos client on our original board with H8 (16-bit, 20MHz), and 436 measured the process time of each Kerberos message [KRBIMPL]. It 437 takes 195 milliseconds to perform a TGS exchange with the on-board 438 H/W crypto engine. Indeed, this result seems reasonable to the 439 requirement of the response time for the control network. However, 440 we did not modify the clock speed of the H8 during our measurement. 441 The processing time must be slower in a actual environment because H8 442 is used with lowered clock speed in such system. With such devices, 443 the delays can grow to unacceptable delays when the number of 444 intermediary realms increases. 446 Satisfying requirements R-1, R-2, R-6 and R-7 will eliminate (or 447 considerably diminish) this issue relating to the client's 448 performance. 450 5.6. Kerberos Pre-authentication problem in roaming scenarios 452 In roaming scenarios, the client needs to contact her home KDC to 453 obtain a cross-realm TGT for the local (or visited) realm. However, 454 the policy of the network access providers or the gateway in the 455 local network usually does not allow clients to communicate with 456 hosts in the Internet unless they provide valid authentication 457 credentials. In this manner, the client encounters a chicken-and-egg 458 problem where two resources are interdependent; the Internet 459 connection is needed to contact the home KDC and for obtaining 460 credentials, and on the other hand, the Internet connection is only 461 granted for clients who have valid credentials. As a result, the 462 Kerberos protocol can not be used as it is for authenticating roaming 463 clients requesting network access. Typically, a VPN approach is 464 applied to solve this problem. However, we can not always establish 465 VPNs between different sites. 467 Satisfying requirements R-3, R-4 and R-5 will eliminate (or 468 considerably diminish) this roaming-related issue pertaining to 469 Kerberos pre-authentication. 471 6. Implementation considerations 473 This document describes issues of the cross-realm operation. There 474 are important matters to be considered, when designing and 475 implementing solutions for these issues. Solution must not introduce 476 new problems. Any solution should use existing components or 477 protocols as much as possible, and it should avoid introducing 478 definitions of new components. It should not require new changes to 479 existing deployed clients, and it should not influence the client 480 code-base as much as possible. Because a KDC is a significant server 481 in an information system based on Kerberos. New burden on the KDC 482 should be minimal. Solutions must take these tradeoffs and the 483 requirements into consideration. On the other hand, solutions are 484 not required to solve all the issues listed in this document at once. 486 7. IANA Considerations 488 This document makes no request of IANA. 490 8. Security Considerations 492 This document clarifies the issues of the cross-realm operation of 493 the Kerberos V system, which include security issues to be 494 considered. See Section 5.1, 5.2, 5.3 and 5.4 for further details. 496 9. Acknowledgements 498 The authors are grateful to Nobuo Okabe, Kazunori Miyazawa, and 499 Atsushi Inoue. They gave us lots of comments and suggestions to this 500 document from the early stage. Nicolas Williams, Chaskiel Grundman 501 and Love Hornquist Astrand gave valuable suggestions and corrections. 502 Thomas Hardjono devoted much work and helped to improve this 503 document. Finally, the authors thank to Jeffrey Hutzelman. He gave 504 us a lot of suggestions for completion of this document. 506 10. References 508 10.1. Normative References 510 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 511 Kerberos Network Authentication Service (V5)", RFC 512 4120, July 2005. 514 10.2. Informative References 516 [CSPC] http://www.shellchemicals.com/news/1,1098,72-news_id= 517 531,00.html 519 [KRBIMPL] "A Prototype of a Secure Autonomous Bootstrap Mechanism 520 for Control Networks", Nobuo Okabe, Shoichi Sakane, 521 Masahiro Ishiyama, Atsushi Inoue and Hiroshi Esaki, 522 SAINT, pp. 56-62, IEEE Computer Society, 2006. 524 [NAM] http://www.nam.nl/ 526 [RNSS-H8] http://www.renesas.com/fmwk.jsp?cnt=h8_family_landing. 527 jsp&fp=/products/mpumcu/h8_family/ 529 [RNSS-M16C] http://www.renesas.com/fmwk.jsp?cnt=m16c_family_landi 530 ng.jsp&fp=/products/mpumcu/m16c_family/ 532 [SHELLCHEM] http://www.shellchemicals.com/home/1,1098,-1,00.html 534 [SPECCROSS] I. Cervesato and A. Jaggard and A. Scedrov and C. 535 Walstad, "Specifying Kerberos 5 Cross-Realm 536 Authentication", Fifth Workshop on Issues in the Theory 537 of Security, Jan 2005. 539 Authors' Addresses 541 Shoichi Sakane 542 Yokogawa Electric Corporation 543 2-9-32 Nakacho, Musashino-shi, 544 Tokyo 180-8750 Japan 545 E-mail: Shouichi.Sakane@jp.yokogawa.com 547 Ken'ichi Kamada 548 Yokogawa Electric Corporation 549 2-9-32 Nakacho, Musashino-shi, 550 Tokyo 180-8750 Japan 551 E-mail: Ken-ichi.Kamada@jp.yokogawa.com 553 Saber Zrelli 554 Yokogawa Electric Corporation 555 2-9-32 Nakacho, Musashino-shi, 556 Tokyo 180-8750 Japan 557 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