idnits 2.17.00 (12 Aug 2021) /tmp/idnits11837/draft-seitz-ace-usecases-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (February 10, 2014) is 3022 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-core-coap has been published as RFC 7252 == Outdated reference: draft-ietf-lwig-terminology has been published as RFC 7228 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group L. Seitz 3 Internet-Draft SICS Swedish ICT AB 4 Intended status: Informational S. Gerdes 5 Expires: August 14, 2014 Universitaet Bremen TZI 6 G. Selander 7 Ericsson 8 February 10, 2014 10 ACE use cases 11 draft-seitz-ace-usecases-00 13 Abstract 15 This document presents use cases for authentication and access 16 control in scenarios involving constrained RESTful devices. Where 17 specific details are relevant, it is assumed that the devices use 18 CoAP as communication protocol, however most conclusions apply 19 generally. 21 A number of security requirements are derived from the use cases, 22 which are intended as a guideline for developing a comprehensive 23 authentication and access control approach for this class of 24 scenarios. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 14, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Container monitoring . . . . . . . . . . . . . . . . . . . 4 64 2.1.1. Bananas for Munich . . . . . . . . . . . . . . . . . . 4 65 2.1.2. Requirements . . . . . . . . . . . . . . . . . . . . . 5 66 2.2. Home Automation . . . . . . . . . . . . . . . . . . . . . 5 67 2.2.1. Remotely letting in a visitor . . . . . . . . . . . . 5 68 2.2.2. Requirements . . . . . . . . . . . . . . . . . . . . . 6 69 2.3. Personal Health Monitoring . . . . . . . . . . . . . . . . 6 70 2.3.1. John and the heart rate monitor . . . . . . . . . . . 7 71 2.3.2. Requirements . . . . . . . . . . . . . . . . . . . . . 8 72 2.4. Building Automation . . . . . . . . . . . . . . . . . . . 8 73 2.4.1. Fire Alarm . . . . . . . . . . . . . . . . . . . . . . 8 74 2.4.2. Requirements . . . . . . . . . . . . . . . . . . . . . 9 75 2.5. Industrial Control Systems . . . . . . . . . . . . . . . . 10 76 2.5.1. Water treatment plant . . . . . . . . . . . . . . . . 10 77 2.5.2. Requirements . . . . . . . . . . . . . . . . . . . . . 11 78 3. Requirements From The Use Cases . . . . . . . . . . . . . . . 12 79 3.1. General Security Requirements . . . . . . . . . . . . . . 12 80 3.2. Authentication Requirements . . . . . . . . . . . . . . . 13 81 3.3. Access Control Requirements . . . . . . . . . . . . . . . 13 82 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 83 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 7. Informative References . . . . . . . . . . . . . . . . . . . . 18 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 88 1. Introduction 90 This document presents use cases in an attempt to analyze the 91 authentication and access control requirements in an Internet of 92 Things setting. This setting features constrained devices 93 [I-D.ietf-lwig-terminology] communicating over the Internet. Some of 94 these devices may have very low capacity in terms of memory and 95 processing power, and may additionally be limited by the fact that 96 they run on battery power. 98 These devices offer resources such as sensor data and actuators, 99 which are accessed by clients, that may be users or other devices. 100 In some situations the communication will happen through 101 intermediaries (e.g. gateways, proxies). 103 Where specific detail is necessary it is assumed that the devices 104 communicate using the CoAP protocol [I-D.ietf-core-coap], although 105 most conclusions are generic. Currently CoAP proposes to use DTLS 106 [RFC6347] for authentication, and access control lists on the 107 devices, that specify which clients may initiate a DTLS connection. 108 One goal of this document is to point out use cases where this 109 approach is not satisfactory. 111 1.1. Terminology 113 Resource Server (RS): The constrained device which hosts resources 114 the Client wants to access. 116 Client (C): A device which wants to access a resource on the Resource 117 Server. 118 This could also be a constrained device. 120 Resource Owner (RO): The subject who owns the resource and controls 121 its access permissions. 123 2. Use Cases 125 This section lists use cases involving constrained devices with 126 security requirements. Each use case first presents a general 127 description of the application area, then one or more specific use 128 cases, and finally the resulting requirements. We assume that basic 129 security requirements such as e.g. communication security and mutual 130 authentication, apply for all of these scenarios. 132 2.1. Container monitoring 134 The ability of sensors to communicate environmental data wirelessly 135 opens up new application areas. The use of such sensor systems makes 136 it possible to transmit specific characteristics such as temperature, 137 humidity and gas content during transportation and storage of goods. 139 The proper handling of the sensors in this scenario is not easy to 140 accomplish. They have to be associated to the appropriate pallet of 141 the respective container. Moreover, the goods and the corresponding 142 sensors belong to specific customers. 144 During the shipment to their destination the goods often pass stops 145 where they are transloaded to other means of transportation, e.g. 146 from ship transport to road transport. 148 2.1.1. Bananas for Munich 150 A Munich supermarket chain buys bananas from a Costa Rican fruit 151 vendor. It instructs a transport company to deliver the goods via 152 ship to Rotterdam where they are picked up by their own company 153 trucks. 155 The supermarket's quality management wants to assure the quality of 156 their products and thus uses the fruit vendor's service of equipping 157 the bananas with sensors. The state of the goods is monitored 158 consistently during the shipment and abnormal sensor values are 159 recorded. Additionally, the sensor values are used to control the 160 climate within the cargo containers. 162 The personnel of the transport company and the supermarket's delivery 163 service has to be able to locate the proper goods and match them to 164 the corresponding customer. The state of the cargo must not be 165 disclosed to them, however. 167 When the goods arrive at the supermarket in Munich, their state is 168 checked. 169 If no anomalies occurred during the transport, the bananas are 170 admitted for sale. 172 2.1.2. Requirements 174 o U1.1 The supermarket chain must be able to allow the transport 175 company and the delivery service to access the position data on 176 the monitoring devices. Other state information must not be 177 accessible. 179 o U1.2 The climate regulation system in the containers must be able 180 to access the monitoring devices' state information to regulate 181 the climate accordingly, without manual intervention of the 182 resource owner. 184 o U1.3 The supermarket chain must be able to allow the supermarket's 185 quality management to access the recorded state information on the 186 monitoring devices. 188 o U1.4 The supermarket chain does not want other companies to be 189 able to read sensor information so there should be some access 190 control for the monitoring devices' state information. 192 2.2. Home Automation 194 Automation of the home, housework or household activity is propagated 195 as a future market for the Internet of Things. A home automation 196 system integrates electrical devices in a house with each other, such 197 as heating, ventilation, lighting, home entertainment and home 198 security. 200 Such a system needs to accommodate a number of regular users 201 (inhabitants, close friends, cleaning personnel) as well as a 202 heterogeneous group of dynamically varying users (visitors, 203 repairmen, delivery men). 205 The security required by the systems integrated in a automated home 206 varies, however it is clear that the security system controlling e.g. 207 the doors, alarms, and other critical systems needs to be at least as 208 secure as for a comparable unautomated home. 210 As the users are not typically trained in security (or even computer 211 use), the configuration must use secure default settings, and the 212 interface must be well adapted to novice users. 214 2.2.1. Remotely letting in a visitor 216 Jane is the owner of an automated home, that allows her to remotely 217 control all electrical devices through a web interface or mobile 218 application. To allow for centralized management of all devices, new 219 devices need to be able to communicate with both the web interface 220 and the mobile application using a standardized, secure protocol. 222 Jane has invited over her acquaintance Jeffrey for dinner, but is 223 stuck in traffic and can not arrive in time, while Jeffrey who uses 224 the subway arrives punctually. Jane calls Jeffrey and offers him to 225 let him in remotely, so he can make himself comfortable and use 226 Jane's home entertainment system. 228 Jeffrey downloads an application that lets him communicate with 229 Jane's home, and Jane set permissions for Jeffery that let's him open 230 the door, and shut down the alarm using that application. She also 231 gives Jeffrey access to lighting and HVAC and limited access to the 232 home entertainment system, allowing Jeffrey to all services except 233 those that are pay-per-use or those that Jane has marked as private. 235 2.2.2. Requirements 237 o U2.1 Jane needs to be able to spontaneously provision 238 authentication means to Jeffrey 240 o U2.2 Jane must be able to spontaneously change the access control 241 policies 243 o U2.3 Jane needs to be able to apply different rights for different 244 devices and users 246 o U2.4 Jane must be able to apply local conditions (presence, time) 247 to authorizations, and the device (e.g. the door) needs to be able 248 to verify these conditions 250 o U2.5 The security mechanisms of the different devices in Jane's 251 home need to be able to communicate with different control devices 252 (e.g. Jeffrey's mobile phone) 254 o U2.6 The access control configuration of Jane's home needs to be 255 secure by default 257 o U2.7 It must be easy for Jane to edit the access control policies 258 for her home, even remotely 260 2.3. Personal Health Monitoring 262 The use of wearable health monitoring technology is expected to grow 263 strongly, as a multitude of novel devices are developed and marketed. 264 These devices are typically battery driven, and located physically on 265 the user. They monitor some bodily function, such as e.g. 266 temperature, blood pressure, or pulse. They are connected to the 267 Internet through an intermediary base-station, using wireless 268 technologies. Through this connection they report the monitored data 269 to some entity, which may either be the user herself, or some medical 270 personnel in charge of the user. 272 Medical data has always been considered as very sensitive, and 273 therefore requires good protection against unauthorized disclosure. 274 A frequent, conflicting requirement is the capability for medical 275 personnel to gain emergency access, even if no specific access rights 276 exist. As a result, the importance of secure audit logs increases in 277 such scenarios. 279 Since the users are not typically trained in security (or even 280 computer use), the configuration must use secure default settings, 281 and the interface must be well adapted to novice users. Also the 282 system must require very little maintenance, so e.g. frequent changes 283 of battery are unacceptable. 285 2.3.1. John and the heart rate monitor 287 John has a heart condition, that can result in sudden cardiac 288 arrests. He therefore uses a device called HeartGuard that monitors 289 his heart rate and his position. In case of a cardiac arrest it 290 automatically sends an alarm to an emergency service, transmitting 291 John's current location. The device also functions as a implanted 292 cardioverter defibrilator, i.e. it can deliver a shock in order to 293 try and normalize Johns heart rate. 295 The device includes some smart logic, with which it identifies its 296 owner John and allows him to configure the device's settings, 297 including access control. 298 This prevents situation where someone else wearing that device can 299 act as the owner and mess up the access control and security 300 settings. 302 John can configure additional persons that get notified in an 303 emergency, for example his daughter Jill. Furthermore the device 304 stores data on John's heart rate, which can later be accessed by a 305 physician to assess the condition of John's heart. 307 However John is a rather private person, and is worried that Jill 308 might use HeartGuard to monitor his location while there is no 309 emergency. Furthermore he doesn't want his health insurance to get 310 access to the HeartGuard data, since they might refuse to renew his 311 insurance if they decided he was too big a risk for them. 313 2.3.2. Requirements 315 o U3.1 John must be able to selectively allow different persons or 316 groups to access the position data on condition that there is an 317 emergency. 319 o U3.2 John must be able to selectively allow different persons or 320 groups to access the heart rate data. 322 o U3.3 John must be able to block access to specific persons or 323 groups, if he mistrusts them. 325 o U3.4 The security measures must not affect the device's battery 326 lifetime significantly 328 o U3.5 The device must have secure access control settings by 329 default 331 o U3.6 The device's access control settings must be easy to 332 configure 334 o U3.7 The device's authentication and access control mechanisms 335 must not open new avenues for denial of service attacks 337 2.4. Building Automation 339 Buildings for commercial use such as shopping malls or office 340 buildings nowadays are equipped increasingly with semi-automatic 341 components to enhance the overall living quality and save energy 342 where possible. This includes for example heating, ventilation and 343 air condition (HVAC) as well as illumination and fire alarm systems. 345 These buildings are often used by more than one company who share 346 some parts of the building while other areas are used by each of them 347 exclusively. Accordingly, a company must be able to control the 348 light and HVAC system of its own part of the building and must not 349 have access to rooms that belong to other companies. 351 Some parts of the building automation system such as entrance 352 illumination and fire alarm systems are controlled either by all 353 parties together or by a service company. 355 2.4.1. Fire Alarm 357 The Companies A and B share an office building which is equipped with 358 a fire alarm system. It is triggered by several smoke detectors 359 which are spread out across the building. 361 It is a really hot day and James who works for company A turns on the 362 air condition in his office. Lucy who works for company B wants to 363 make tea using an electric kettle. After she turned it on she goes 364 outside to talk to a colleague until the water is boiling. 365 Unfortunately, her kettle has a malfunction which causes overheating 366 and results in a smoldering fire of the kettle's plastic case. 368 Due to the smoke coming from the kettle the fire alarm is triggered. 369 Alarm sirens throughout the building are notified and alert the staff 370 of both companies. Additionally, the ventilation system of the whole 371 building is closed off to prevent the smoke from spreading and to 372 withdraw oxygen from the fire. The smoke cannot get into James' 373 office although he turned on his air condition because the fire alarm 374 overrides the manual setting. 376 The fire department is notified of the fire automatically and arrives 377 within a short time. After inspecting the damage and extinguishing 378 the smoldering fire a fire fighter resets the fire alarm because only 379 the fire department is authorized to do that. 381 2.4.2. Requirements 383 o U4.1 Different subsystems of the building must be able 384 interoperate with each other, e.g. the ventilation with the fire 385 alarm. The affected devices might be produced by different 386 vendors and might be operated by different service providers. 388 o U4.2 Only the smoke detectors must be able to trigger an alarm. 390 o U4.3 Only the fire department must be able to reset the fire 391 alarm. 393 o U4.4 James must be able to control the air conditioning in his 394 office. 396 o U4.5 The emergency system must be able to automatically close off 397 the ventilation system, without manual intervention of the 398 resource owner. 400 o U4.6 During fire alarm, the personnel must not be allowed to 401 regulate the climate control. 403 o U4.7 Since physically accessing the devices in the building is 404 very work intensive and thus expensive (there are many devices, 405 and some are in places that are hard to access), the security 406 measures should not affect battery lifetime significantly and not 407 require direct physical interaction with individual devices. 409 2.5. Industrial Control Systems 411 Industrial control systems (ICS) and especially supervisory control 412 and data acquisition systems (SCADA) use a multitude of sensors and 413 actuators in order to monitor and control industrial processes in the 414 physical world. Example processes include manufacturing, power 415 generation, and refining of raw materials. 417 Since the advent of the Stuxnet worm it has become obvious to the 418 general public how vulnerable this kind of systems are, especially 419 when connected to the Internet. The severity of these 420 vulnerabilities are exacerbated by the fact that many ICS are used to 421 control critical public infrastructure, such as power, water 422 treatment of traffic control. 423 Nevertheless the economical advantages of connecting such systems to 424 the Internet can be significant if appropriate security measures are 425 put in place. 427 2.5.1. Water treatment plant 429 The communal water treatment plant of a mid-sized city is controlled 430 by a networked ICS. Spread across the city are numerous nodes, 431 sensors (e.g. pollution meters, pressure indicators) and actuators 432 (e.g. valves, pumps) communicating via a wireless network. Since the 433 range of the network is limited, many nodes communicate through 434 intermediary proxies that relay communications to the administration 435 clients of the ICS. 437 Jenny is a technician whose job it is to monitor the plant and take 438 appropriate measure, if abnormal conditions are detected (e.g. if 439 water pollution is detected, or the pressure in a pump reaches 440 critical levels). 441 Jenny uses an observation mechanism on certain critical resources 442 that sends her automatic notifications in case of some unexpected 443 state change. 445 If Jenny needs to go on sick-leave spontaneously, the service company 446 sends a replacement worker from a pool of available, qualified 447 persons. The security administrators give the replacement 448 appropriate access rights to the system, without sharing Jenny's 449 credentials (e.g. her password, access card, or private key) with 450 him, furthermore this delegation does not require updates of the 451 access control information on the devices. 453 Joshuah is a young, computer savvy kid with too much time at his 454 hands. He spends time wardriving and stumbles upon the wireless 455 network, used by the plant's sensors and actuators. Joshuah tries to 456 interact with the devices on this network and manages to stall a 457 valve controlling water flow to a part of the city, by overloading 458 its controller with fake requests for secure connections. Jenny 459 quickly discovers the attack and is able to take appropriate measures 460 to prevent damage to the value and restore normal service conditions. 462 2.5.2. Requirements 464 o U5.1 The authentication and access control measures must cope with 465 the presence of intermediary proxies between the Resource Server 466 and the Client. 468 o U5.2 Since most of the processing capacity of the nodes and the 469 network load capacity must go towards production tasks, the 470 security measures must use minimal resources, both on the network 471 and on the nodes. 473 o U5.3 Since replacement workers can spontaneously jump in for 474 Jenny, the system needs to be able to handle authentication and 475 access control updates without re-provisioning each node 476 individually. 478 o U5.4 After a replacement worker has finished taking care of the 479 system, the corresponding access control and authentication means 480 need to be revoked, without re-provisioning each node 481 individually. 483 o U5.5 The authentication and access control mechanisms must not 484 introduce additional avenues for denial of service attacks. 486 3. Requirements From The Use Cases 488 This section lists requirements derived from the use cases above. 489 Note that not every single requirement applies to every Resource 490 Server, however protocols should allow for all of these requirements 491 to be fulfilled. 493 3.1. General Security Requirements 495 The following requirements refer to general security measures that 496 are affected by the design of authentication and access control 497 protocols. 499 o Protect the Resource Server against denial of service (U3.7, U5.5) 501 * Minimize the number of protocol steps that an attacker can 502 induce a Resource Server to perform without proper 503 authentication and access control. 505 * Note well that for constrained devices this includes attacks 506 that aim to drain the battery of the target. 508 o Authentication and access control measures must work when traffic 509 from the Client to the Resource Server goes through intermediary 510 nodes. (U5.1) 512 Rationale: In many deployments, there will be gateways, proxies, 513 firewalls etc. between a Client and a Resource Server. This means 514 that e.g. DTLS client authentication can not be used to 515 authenticate the Client. 517 o Minimize resource usage for authentication and access control on 518 the constrained device(s) (U3.4, U4.7, U5.2) 520 * Minimize battery usage 522 + Minimize message exchanges required by security measures 524 + Minimize the size of authentication and access control data 525 that is transmitted 527 + Minimize the size of required software libraries 529 + Minimize memory and stack usage on the devices 531 o Require secure default settings (U1.4, U2.6, U3.5) 533 Rationale: Many attacks exploit insecure default settings, and 534 experience shows that default settings are frequently left 535 unchanged by the end users. Therefore the security protocols for 536 constrained devices should require secure modes of use by default. 538 o Interoperability (U1.1, U2.5, U4.1) 540 Rationale: Resource Owners may interact with Clients from various 541 manufacturers and vice-versa. In order to function correctly the 542 authentication and access control mechanisms need to work 543 together. 544 This is best achieved by standardization. 546 o Usability (U2.7, U3.6) 548 * Keep response times reasonable 550 * Make authentication and access control transparent for human 551 users where possible 553 * Make the administration of authentication and access control as 554 simple as possible 556 3.2. Authentication Requirements 558 o Standardized provisioning of authentication means to Clients and 559 Resource Servers (U2.1, U5.3) 561 * Allow for remote provisioning as an option 563 o Enable remote revocation of authentication means (U5.4) 565 3.3. Access Control Requirements 567 o Enforce the access control policies of the Resource Owner (all use 568 cases) 570 * Provision access control policies set by the Resource Owner to 571 the Policy Decision Point [RFC2904] (which may be on the 572 Resource Server or on another trusted entity). 574 * Apply the access control policies to incoming requests (this 575 may be done by the Resource Server or by another trusted 576 entity). 578 o Apply different rights for different requesting entities (U1.1, 579 U1.2, U2.3, U3.1, U3.2, U3.3, U4.2, U4.3, U4.4, U4.5) 581 Rationale: In some cases different types of users require 582 different access rights, as opposed to all-or-nothing access 583 control. 585 o Allow for fine-grained access control (U1.1, U1.2, U3.1, U3.2, 586 U4.2, U4.3, U4.4, U4.5) Resource Servers can host several 587 resources, and a resource (e.g. an actuator) can have different 588 settings. In some cases access rights need to be different at 589 this level of granularity. 591 o Enable checking of local conditions (U2.4, U3.1, U4.6) Access may 592 depend on local conditions e.g. access to health data in an 593 emergency. The Policy Decision Point must be able to take such 594 conditions into account. 596 o Enable policy updates without re-provisioning individual devices 597 (U2.2, U4.7, U5.3, U5.4) 599 Rationale: Clients can change rapidly and re-provisioning might be 600 prohibitively expensive. 602 o Do not require manual intervention of the Resource Owner in the 603 access control process (U1.2, U3.1, U4.5). 605 Rationale: Manually approving access requests, while being a 606 common solution in web access control, does not scale well in an 607 M2M scenario. 609 4. Security Considerations 611 This document lists security requirements for constrained devices, 612 motivated by specific use cases. Therefore the whole document deals 613 with security considerations. 615 5. Acknowledgments 617 The authors would like to thank Olaf Bergmann, Sumit Singhal, John 618 Mattson, and Mohit Sethi for reviewing and contributing to the 619 document. Also, thanks to Markus Becker for his input on the 620 container monitoring use case. 622 6. IANA Considerations 624 This document has no IANA actions. 626 7. Informative References 628 [I-D.ietf-core-coap] 629 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 630 Application Protocol (CoAP)", draft-ietf-core-coap-18 631 (work in progress), June 2013. 633 [I-D.ietf-lwig-terminology] 634 Bormann, C., Ersue, M., and A. Keranen, "Terminology for 635 Constrained Node Networks", draft-ietf-lwig-terminology-06 636 (work in progress), December 2013. 638 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 639 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 640 D. Spence, "AAA Authorization Framework", RFC 2904, 641 August 2000. 643 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 644 Security Version 1.2", RFC 6347, January 2012. 646 Authors' Addresses 648 Ludwig Seitz 649 SICS Swedish ICT AB 650 Scheelevaegen 17 651 Lund 22370 652 Sweden 654 Email: ludwig@sics.se 656 Stefanie Gerdes 657 Universitaet Bremen TZI 658 Postfach 330440 659 Bremen D-28359 660 Germany 662 Phone: +49-421-218-63906 663 Email: gerdes@tzi.org 665 Goeran Selander 666 Ericsson 667 Faroegatan 6 668 Kista 16480 669 Sweden 671 Email: goran.selander@ericsson.com