draft-ietf-lwig-crypto-sensors-00.txt | draft-ietf-lwig-crypto-sensors-01.txt | |||
---|---|---|---|---|
Light-Weight Implementation Guidance M. Sethi | Light-Weight Implementation Guidance M. Sethi | |||
Internet-Draft J. Arkko | Internet-Draft J. Arkko | |||
Intended status: Informational A. Keranen | Intended status: Informational A. Keranen | |||
Expires: March 8, 2017 Ericsson | Expires: May 4, 2017 Ericsson | |||
H. Back | H. Back | |||
Comptel | Comptel | |||
September 4, 2016 | October 31, 2016 | |||
Practical Considerations and Implementation Experiences in Securing | Practical Considerations and Implementation Experiences in Securing | |||
Smart Object Networks | Smart Object Networks | |||
draft-ietf-lwig-crypto-sensors-00 | draft-ietf-lwig-crypto-sensors-01 | |||
Abstract | Abstract | |||
This memo describes challenges associated with securing smart object | This memo describes challenges associated with securing smart object | |||
devices in constrained implementations and environments. The memo | devices in constrained implementations and environments. The memo | |||
describes a possible deployment model suitable for these | describes a possible deployment model suitable for these | |||
environments, discusses the availability of cryptographic libraries | environments, discusses the availability of cryptographic libraries | |||
for small devices, presents some preliminary experiences in | for small devices, presents some preliminary experiences in | |||
implementing small devices using those libraries, and discusses | implementing small devices using those libraries, and discusses | |||
trade-offs involving different types of approaches. | trade-offs involving different types of approaches. | |||
skipping to change at page 1, line 40 ¶ | skipping to change at page 1, line 40 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on March 8, 2017. | This Internet-Draft will expire on May 4, 2017. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2016 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 17 ¶ | skipping to change at page 2, line 17 ¶ | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 5 | 4. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 5 | |||
5. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 5 | 5. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
6. Protocol Architecture . . . . . . . . . . . . . . . . . . . . 8 | 6. Protocol Architecture . . . . . . . . . . . . . . . . . . . . 8 | |||
7. Code Availability . . . . . . . . . . . . . . . . . . . . . . 8 | 7. Code Availability . . . . . . . . . . . . . . . . . . . . . . 9 | |||
8. Implementation Experiences . . . . . . . . . . . . . . . . . 10 | 8. Implementation Experiences . . . . . . . . . . . . . . . . . 11 | |||
9. Example Application . . . . . . . . . . . . . . . . . . . . . 16 | 9. Example Application . . . . . . . . . . . . . . . . . . . . . 17 | |||
10. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 20 | 10. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 21 | |||
11. Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 20 | 11. Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
12. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 21 | 12. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
13. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 23 | 13. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
14. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . . . 25 | 14. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . . . 26 | |||
15. Security Considerations . . . . . . . . . . . . . . . . . . . 25 | 15. Security Considerations . . . . . . . . . . . . . . . . . . . 26 | |||
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 | 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 | |||
17. Informative references . . . . . . . . . . . . . . . . . . . 26 | 17. Informative references . . . . . . . . . . . . . . . . . . . 26 | |||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 31 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 32 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
1. Introduction | 1. Introduction | |||
This memo describes challenges associated with securing smart object | This memo describes challenges associated with securing smart object | |||
devices in constrained implementations and environments (see | devices in constrained implementations and environments. In | |||
Section 3). | Section 3) we specifically discuss three challenges: the | |||
implementation difficulties encountered on resource-constrained | ||||
platforms, the problem of provisioning keys and making the choice of | ||||
implementing security at the appropriate layer. | ||||
Secondly, Section 4 discusses a deployment model that the authors are | Secondly, Section 4 discusses a deployment model that the authors are | |||
considering for constrained environments. The model requires minimal | considering for constrained environments. The model requires minimal | |||
amount of configuration, and we believe it is a natural fit with the | amount of configuration, and we believe it is a natural fit with the | |||
typical communication practices smart object networking environments. | typical communication practices in smart object networking | |||
environments. | ||||
Thirdly, Section 7 discusses the availability of cryptographic | Thirdly, Section 7 discusses the availability of cryptographic | |||
libraries. Section 8 presents some experiences in implementing small | libraries. Section 8 presents some experiences in implementing | |||
devices using those libraries, including information about achievable | cryptography on small devices using those libraries, including | |||
code sizes and speeds on typical hardware. | information about achievable code sizes and speeds on typical | |||
hardware. | ||||
Finally, Section 10 discusses trade-offs involving different types of | Finally, Section 10 discusses trade-offs involving different types of | |||
security approaches. | security approaches. | |||
2. Related Work | 2. Related Work | |||
Constrained Application Protocol (CoAP) [RFC7252] is a light-weight | Constrained Application Protocol (CoAP) [RFC7252] is a light-weight | |||
protocol designed to be used in machine-to-machine applications such | protocol designed to be used in machine-to-machine applications such | |||
as smart energy and building automation. Our discussion uses this | as smart energy and building automation. Our discussion uses this | |||
protocol as an example, but the conclusions may apply to other | protocol as an example, but the conclusions may apply to other | |||
similar protocols. CoAP base specification [RFC7252] outlines how to | similar protocols. CoAP base specification [RFC7252] outlines how to | |||
use DTLS [RFC6347] and IKEv2 [RFC7296] for securing the protocol. | use DTLS [RFC6347] and IPsec [RFC4303] for securing the protocol. | |||
DTLS can be applied with group keys, pairwise shared keys, or with | DTLS can be applied with pairwise shared keys, raw public keys or | |||
certificates. The security model in all cases is mutual | with certificates. The security model in all cases is mutual | |||
authentication, so while there is some commonality to HTTP in | authentication, so while there is some commonality to HTTP in | |||
verifying the server identity, in practice the models are quite | verifying the server identity, in practice the models are quite | |||
different. The specification says little about how DTLS keys are | different. The CoAP specification says little about how DTLS keys | |||
managed. The IPsec mode is described with regards to the protocol | are managed. The use of IPsec with CoAP is described with regards to | |||
requirements, noting that small implementations of IKEv2 exist | the protocol requirements, noting that small implementations of IKEv2 | |||
[RFC7815]. However, the specification is silent on policy and other | exist [RFC7815]. However, the CoAP specification is silent on policy | |||
aspects that are normally necessary in order to implement | and other aspects that are normally necessary in order to implement | |||
interoperable use of IPsec in any environment [RFC5406]. | interoperable use of IPsec in any environment [RFC5406]. | |||
[RFC6574] gives an overview of the security discussions at the March | [RFC6574] gives an overview of the security discussions at the March | |||
2011 IAB workshop on smart objects. The workshop recommended that | 2011 IAB workshop on smart objects. The workshop recommended that | |||
additional work is needed in developing suitable credential | additional work is needed in developing suitable credential | |||
management mechanisms (perhaps something similar to the Bluetooth | management mechanisms (perhaps something similar to the Bluetooth | |||
pairing mechanism), understanding the implementability of standard | pairing mechanism), understanding the implementability of standard | |||
security mechanisms in small devices and additional research in the | security mechanisms in small devices and additional research in the | |||
area of lightweight cryptographic primitives. | area of lightweight cryptographic primitives. | |||
skipping to change at page 3, line 50 ¶ | skipping to change at page 4, line 7 ¶ | |||
[I-D.daniel-6lowpan-security-analysis] makes a comprehensive analysis | [I-D.daniel-6lowpan-security-analysis] makes a comprehensive analysis | |||
of security issues related to 6LoWPAN networks, but its findings also | of security issues related to 6LoWPAN networks, but its findings also | |||
apply more generally for all low-powered networks. Some of the | apply more generally for all low-powered networks. Some of the | |||
issues this document discusses include the need to minimize the | issues this document discusses include the need to minimize the | |||
number of transmitted bits and simplify implementations, threats in | number of transmitted bits and simplify implementations, threats in | |||
the smart object networking environments, and the suitability of | the smart object networking environments, and the suitability of | |||
6LoWPAN security mechanisms, IPsec, and key management protocols for | 6LoWPAN security mechanisms, IPsec, and key management protocols for | |||
implementation in these environments. | implementation in these environments. | |||
[I-D.garcia-core-security] discusses the overall security problem for | [I-D.irtf-t2trg-iot-seccons] discusses the overall security problem | |||
Internet of Things devices. It also discusses various solutions, | for Internet of Things devices. It also discusses various solutions, | |||
including IKEv2/IPsec [RFC7296], TLS/SSL [RFC5246], DTLS [RFC6347], | including IKEv2/IPsec [RFC7296], TLS/SSL [RFC5246], DTLS [RFC6347], | |||
HIP [RFC7401] [I-D.moskowitz-hip-dex], PANA [RFC5191], and EAP | HIP [RFC7401] [I-D.moskowitz-hip-dex], PANA [RFC5191], and EAP | |||
[RFC3748]. The draft also discusses various operational scenarios, | [RFC3748]. The draft also discusses various operational scenarios, | |||
bootstrapping mechanisms, and challenges associated with implementing | bootstrapping mechanisms, and challenges associated with implementing | |||
security mechanisms in these environments. | security mechanisms in these environments. | |||
3. Challenges | 3. Challenges | |||
This section discusses three challenges: implementation difficulties, | This section discusses three challenges: implementation difficulties, | |||
practical provisioning problems, and layering and communication | practical provisioning problems, and layering and communication | |||
skipping to change at page 5, line 40 ¶ | skipping to change at page 5, line 47 ¶ | |||
The basis of the proposed architecture are self-generated secure | The basis of the proposed architecture are self-generated secure | |||
identities, similar to Cryptographically Generated Addresses (CGAs) | identities, similar to Cryptographically Generated Addresses (CGAs) | |||
[RFC3972] or Host Identity Tags (HITs) [RFC7401]. That is, we assume | [RFC3972] or Host Identity Tags (HITs) [RFC7401]. That is, we assume | |||
the following holds: | the following holds: | |||
I = h(P|O) | I = h(P|O) | |||
where I is the secure identity of the device, h is a hash function, P | where I is the secure identity of the device, h is a hash function, P | |||
is the public key from a key pair generated by the device, and O is | is the public key from a key pair generated by the device, and O is | |||
optional other information. | optional other information. | here denotes the concatenation | |||
operator. | ||||
5. Provisioning | 5. Provisioning | |||
As provisioning security credentials, shared secrets, and policy | As it is difficult to provision security credentials, shared secrets, | |||
information is difficult, the provisioning model is based only on the | and policy information, the provisioning model is based only on the | |||
secure identities. A typical network installation involves physical | secure identities. A typical network installation involves physical | |||
placement of a number of devices while noting the identities of these | placement of a number of devices while noting the identities of these | |||
devices. This list of short identifiers can then be fed to a central | devices. This list of short identifiers can then be fed to a central | |||
server as a list of authorized devices. Secure communications can | server as a list of authorized devices. Secure communications can | |||
then commence with the devices, at least as far as information from | then commence with the devices, at least as far as information from | |||
from the devices to the server is concerned, which is what is needed | from the devices to the server is concerned, which is what is needed | |||
for sensor networks. | for sensor networks. | |||
The above architecture is a perfect fit for sensor networks where | The above architecture is a perfect fit for sensor networks where | |||
information flows from large number of devices to small number of | information flows from large number of devices to small number of | |||
skipping to change at page 9, line 20 ¶ | skipping to change at page 9, line 33 ¶ | |||
environment. Note that the results are preliminary, and could easily | environment. Note that the results are preliminary, and could easily | |||
be affected in any direction by implementation bugs, configuration | be affected in any direction by implementation bugs, configuration | |||
errors, and other mistakes. Please verify the numbers before relying | errors, and other mistakes. Please verify the numbers before relying | |||
on them for building something. No significant effort was done to | on them for building something. No significant effort was done to | |||
optimize ROM memory usage beyond what the libraries provided | optimize ROM memory usage beyond what the libraries provided | |||
themselves, so those numbers should be taken as upper limits. | themselves, so those numbers should be taken as upper limits. | |||
Here is the set of libraries we found: | Here is the set of libraries we found: | |||
o AvrCryptolib [avr-cryptolib]: This library provides a variety of | o AvrCryptolib [avr-cryptolib]: This library provides a variety of | |||
different symmetric key algorithms such as DES/Triple DES/AES etc. | different symmetric key algorithms such as AES and RSA as an | |||
and RSA as an asymmetric key algorithm. We stripped down the | asymmetric key algorithm. We stripped down the library to use | |||
library to use only the required RSA components and used a | only the required RSA components and used a separate SHA-256 | |||
separate SHA-256 implementation from the original AvrCrypto-Lib | implementation from the original AvrCrypto-Lib library | |||
library [avr-crypto-lib]. Parts of SHA-256 and RSA algorithm | [avr-crypto-lib]. Parts of SHA-256 and RSA algorithm | |||
implementations were written in AVR-8 bit assembly language to | implementations were written in AVR-8 bit assembly language to | |||
reduce the size and optimize the performance. The library also | reduce the size and optimize the performance. The library also | |||
takes advantage of the fact that Arduino boards allow the | takes advantage of the fact that Arduino boards allow the | |||
programmer to directly address the flash memory to access constant | programmer to directly address the flash memory to access constant | |||
data which can save the amount of SRAM used during execution. | data which can save the amount of SRAM used during execution. | |||
o Relic-Toolkit [relic-toolkit]: This library is written entirely in | o Relic-Toolkit [relic-toolkit]: This library is written entirely in | |||
C and provides a highly flexible and customizable implementation | C and provides a highly flexible and customizable implementation | |||
of a large variety of cryptographic algorithms. This not only | of a large variety of cryptographic algorithms. This not only | |||
includes RSA and ECC, but also pairing based asymmetric | includes RSA and ECC, but also pairing based asymmetric | |||
skipping to change at page 10, line 44 ¶ | skipping to change at page 11, line 10 ¶ | |||
original form takes about 50 kB of ROM which is not suitable for | original form takes about 50 kB of ROM which is not suitable for | |||
our hardware requirements. Moreover, it is intended for 32-bit | our hardware requirements. Moreover, it is intended for 32-bit | |||
systems and the API includes functions for SSL communication | systems and the API includes functions for SSL communication | |||
rather than just signing data with private keys. | rather than just signing data with private keys. | |||
This is by no ways an exhaustive list and there exist other | This is by no ways an exhaustive list and there exist other | |||
cryptographic libraries targeting resource-constrained devices. | cryptographic libraries targeting resource-constrained devices. | |||
8. Implementation Experiences | 8. Implementation Experiences | |||
While evaluating the implementation experiences, we were particularly | ||||
interested in the signature generation operation. This was because | ||||
our example application discussed in Section 9 required only the | ||||
signature generation operation on the resource-constrained platforms. | ||||
We have summarized the initial results of RSA private key performance | We have summarized the initial results of RSA private key performance | |||
using AvrCryptolib in Table 1. All results are from a single run | using AvrCryptolib in Table 1. All results are from a single run | |||
since repeating the test did not change (or had only minimal impact | since repeating the test did not change (or had only minimal impact | |||
on) the results. The keys were generated separately and were hard | on) the results. The keys were generated separately and were hard | |||
coded into the program. All keys were generated with the value of | coded into the program. All keys were generated with the value of | |||
the public exponent as 3. The performance of signing with private | the public exponent as 3. The performance of signing with private | |||
key was faster for smaller key lengths as was expected. However the | key was faster for smaller key lengths as was expected. However the | |||
increase in the execution time was considerable when the key size was | increase in the execution time was considerable when the key size was | |||
2048 bits. It is important to note that two different sets of | 2048 bits. It is important to note that two different sets of | |||
experiments were performed for each key length. In the first case, | experiments were performed for each key length. In the first case, | |||
skipping to change at page 26, line 45 ¶ | skipping to change at page 27, line 35 ¶ | |||
Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. | Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. | |||
Novo, "Implementing Tiny COAP Sensors", draft-arkko-core- | Novo, "Implementing Tiny COAP Sensors", draft-arkko-core- | |||
sleepy-sensors-01 (work in progress), July 2011. | sleepy-sensors-01 (work in progress), July 2011. | |||
[I-D.daniel-6lowpan-security-analysis] | [I-D.daniel-6lowpan-security-analysis] | |||
Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J. | Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J. | |||
Laganier, "IPv6 over Low Power WPAN Security Analysis", | Laganier, "IPv6 over Low Power WPAN Security Analysis", | |||
draft-daniel-6lowpan-security-analysis-05 (work in | draft-daniel-6lowpan-security-analysis-05 (work in | |||
progress), March 2011. | progress), March 2011. | |||
[I-D.garcia-core-security] | ||||
Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and | ||||
R. Struik, "Security Considerations in the IP-based | ||||
Internet of Things", draft-garcia-core-security-06 (work | ||||
in progress), September 2013. | ||||
[I-D.ietf-core-resource-directory] | [I-D.ietf-core-resource-directory] | |||
Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE | Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE | |||
Resource Directory", draft-ietf-core-resource-directory-08 | Resource Directory", draft-ietf-core-resource-directory-08 | |||
(work in progress), July 2016. | (work in progress), July 2016. | |||
[I-D.irtf-cfrg-eddsa] | [I-D.irtf-cfrg-eddsa] | |||
Josefsson, S. and I. Liusvaara, "Edwards-curve Digital | Josefsson, S. and I. Liusvaara, "Edwards-curve Digital | |||
Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-08 | Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-08 | |||
(work in progress), August 2016. | (work in progress), August 2016. | |||
[I-D.irtf-t2trg-iot-seccons] | ||||
Garcia-Morchon, O., Kumar, S., and M. Sethi, "Security | ||||
Considerations in the IP-based Internet of Things", draft- | ||||
irtf-t2trg-iot-seccons-00 (work in progress), October | ||||
2016. | ||||
[I-D.jennings-core-senml] | [I-D.jennings-core-senml] | |||
Jennings, C., Shelby, Z., Arkko, J., and A. Keranen, | Jennings, C., Shelby, Z., Arkko, J., and A. Keranen, | |||
"Media Types for Sensor Markup Language (SenML)", draft- | "Media Types for Sensor Markup Language (SenML)", draft- | |||
jennings-core-senml-06 (work in progress), April 2016. | jennings-core-senml-06 (work in progress), April 2016. | |||
[I-D.moskowitz-hip-dex] | [I-D.moskowitz-hip-dex] | |||
Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", | Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", | |||
draft-moskowitz-hip-dex-05 (work in progress), January | draft-moskowitz-hip-dex-05 (work in progress), January | |||
2016. | 2016. | |||
skipping to change at page 28, line 14 ¶ | skipping to change at page 29, line 5 ¶ | |||
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. | [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. | |||
Levkowetz, Ed., "Extensible Authentication Protocol | Levkowetz, Ed., "Extensible Authentication Protocol | |||
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, | (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, | |||
<http://www.rfc-editor.org/info/rfc3748>. | <http://www.rfc-editor.org/info/rfc3748>. | |||
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", | [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", | |||
RFC 3972, DOI 10.17487/RFC3972, March 2005, | RFC 3972, DOI 10.17487/RFC3972, March 2005, | |||
<http://www.rfc-editor.org/info/rfc3972>. | <http://www.rfc-editor.org/info/rfc3972>. | |||
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", | ||||
RFC 4303, DOI 10.17487/RFC4303, December 2005, | ||||
<http://www.rfc-editor.org/info/rfc4303>. | ||||
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., | [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., | |||
and A. Yegin, "Protocol for Carrying Authentication for | and A. Yegin, "Protocol for Carrying Authentication for | |||
Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, | Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, | |||
May 2008, <http://www.rfc-editor.org/info/rfc5191>. | May 2008, <http://www.rfc-editor.org/info/rfc5191>. | |||
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | |||
(TLS) Protocol Version 1.2", RFC 5246, | (TLS) Protocol Version 1.2", RFC 5246, | |||
DOI 10.17487/RFC5246, August 2008, | DOI 10.17487/RFC5246, August 2008, | |||
<http://www.rfc-editor.org/info/rfc5246>. | <http://www.rfc-editor.org/info/rfc5246>. | |||
End of changes. 20 change blocks. | ||||
46 lines changed or deleted | 60 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |