< draft-chunduri-karp-kmp-router-fingerprints-03.txt		draft-chunduri-karp-kmp-router-fingerprints-04.txt >
	Working Group U. Chunduri		Working Group U. Chunduri
	Internet-Draft A. Tian		Internet-Draft A. Tian
	Intended status: Informational A. Keranen		Intended status: Informational A. Keranen
	Expires: September 12, 2013 Ericsson		Expires: April 23, 2014 Ericsson
	T. Kivinen		T. Kivinen
	INSIDE Secure		INSIDE Secure
	March 11, 2013		October 20, 2013
	KARP KMP: Simplified Peer Authentication		KARP KMP: Simplified Peer Authentication
	draft-chunduri-karp-kmp-router-fingerprints-03		draft-chunduri-karp-kmp-router-fingerprints-04
	Abstract		Abstract
	This document describes the usage of Router Fingerprint		This document describes the usage of Router Fingerprint
	Authentication (RFA) with public keys as a potential peer		Authentication (RFA) with public keys as a potential peer
	authentication method with KARP pair wise and group Key Management		authentication method with KARP pair wise and group Key Management
	Protocols (KMPs). The advantage of RFA is, it neither requires out-		Protocols (KMPs). The advantage of RFA is, it neither requires out-
	of-band, mutually agreeable symmetric keys nor a full PKI based		of-band, mutually agreeable symmetric keys nor a full PKI based
	system (trust anchor or CA certificates) for mutual authentication of		system (trust anchor or CA certificates) for mutual authentication of
	peers with KARP KMP deployments. Usage of Router Fingerprints give a		peers with KARP KMP deployments. Usage of Router Fingerprints give a
	significant operational improvement from symmetric key based systems		significant operational improvement from symmetric key based systems
	and yet provide a secure authentication technique.		and yet provide a secure authentication technique.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 September 12, 2013.		This Internet-Draft will expire on April 23, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Router Fingerprint . . . . . . . . . . . . . . . . . . . . . . 4		2. Router Fingerprint . . . . . . . . . . . . . . . . . . . . . 4
	3. Usage of Router Fingerprints with KARP KMP . . . . . . . . . . 5		3. Usage of Router Fingerprints with KARP KMP . . . . . . . . . 4
	3.1. Impact on the PAD . . . . . . . . . . . . . . . . . . . . 6		4. Publishing Router Fingerprints . . . . . . . . . . . . . . . 5
	4. Publishing Router Fingerprints . . . . . . . . . . . . . . . . 6		5. Scope of Fingerprints usage with RPs . . . . . . . . . . . . 6
	5. Scope of Fingerprints usage with RPs . . . . . . . . . . . . . 6		6. Fingerprint Revocation . . . . . . . . . . . . . . . . . . . 6
	6. Fingerprint Revocation . . . . . . . . . . . . . . . . . . . . 7		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 7		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8		10. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . 7
	10. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 8		10.1. Applicable Authentications methods . . . . . . . . . . . 7
	10.1. Applicable Authentications methods . . . . . . . . . . . . 8		10.1.1. Symmetric key based authentication . . . . . . . . . 7
	10.1.1. Symmetric key based authentication . . . . . . . . . 8		10.1.2. Asymmetric key based authentication . . . . . . . . 8
	10.1.2. Asymmetric key based authentication . . . . . . . . . 9		10.1.3. EAP based authentication . . . . . . . . . . . . . . 8
	10.1.3. EAP based authentication . . . . . . . . . . . . . . 9		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		11.1. Normative References . . . . . . . . . . . . . . . . . . 9
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 10		11.2. Informative References . . . . . . . . . . . . . . . . . 9
	11.2. Informative References . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	Usage of IKEv2[RFC5996] as the KMP for with specific extensions for		Usage of IKEv2[RFC5996] as the KMP for with specific extensions for
	pair wise routing protocols (RPs) is described in [mahesh-karp-rkmp].		pair wise routing protocols (RPs) is described in [mahesh-karp-rkmp].
	Also IKEv2 based KMP for group keying RPs is described in [hartman-		Also IKEv2 based KMP for group keying RPs is described in [hartman-
	karp-mrkmp]. With proliferation of authentication methods supported		karp-mrkmp]. With proliferation of authentication methods supported
	by IKEv2, this draft explores a simple and secure peer authentication		by IKEv2, this draft explores a simple and secure peer authentication
	method, which can be potentially used for all KARP KMP deployments.		method, which can be potentially used for all KARP KMP deployments.
	Currently operators don't often change the manual keys deployed for		Currently operators don't often change the manual keys deployed for
	protecting RP messages because of various reasons as noted in Section		protecting RP messages because of various reasons as noted in
	2.3 of KARP threat document [I-D.ietf-karp-threats-reqs]. One of the		Section 2.3 of KARP threat document [RFC6862]. One of the KARP WG
	KARP WG goals is to define methods to support key changes for all RPs		goals is to define methods to support key changes for all RPs which
	which use either Manual Key Management (MKM) or KMP without much		use either Manual Key Management (MKM) or KMP without much
	operational overhead.		operational overhead.
	Apart from Peer's identity verification, authentication and parameter		Apart from Peer's identity verification, authentication and parameter
	negotiation, deployment of KMP can be more useful, when it comes to		negotiation, deployment of KMP can be more useful, when it comes to
	rekey the keys used by RPs. Rekeying can be achieved without the		rekey the keys used by RPs. Rekeying can be achieved without the
	operator's intervention and as per the provisioned rekey policy. But		operator's intervention and as per the provisioned rekey policy. But
	for operators, usage of IKEv2 KMP opens up numerous possibilities for		for operators, usage of IKEv2 KMP opens up numerous possibilities for
	peer authentication and manual symmetric keys are not only used for		peer authentication and manual symmetric keys are not only used for
	bootstrapping KMP, but used for peer authentication. Various other		bootstrapping KMP, but used for peer authentication. Various other
	peer authentication mechanisms with advantages/drawbacks of each		peer authentication mechanisms with advantages/drawbacks of each
	skipping to change at page 5, line 24 ¶		skipping to change at page 5, line 4 ¶
	3. The result should be hashed with a cryptographic hash function,		3. The result should be hashed with a cryptographic hash function,
	preferably SHA-256 or hash functions with similar strength (see		preferably SHA-256 or hash functions with similar strength (see
	more discussion on choosing preferred hash function in		more discussion on choosing preferred hash function in
	Section 8).		Section 8).
	The fingerprint generated is not a secret and can be distributed		The fingerprint generated is not a secret and can be distributed
	publicly. This is further discussed in Section 4.		publicly. This is further discussed in Section 4.
	3. Usage of Router Fingerprints with KARP KMP		3. Usage of Router Fingerprints with KARP KMP
	To use Router Fingerprints authentication with KARP KMP, a Private/		To use Router Fingerprints authentication with KARP KMP, a Private/
	Public key-pair MUST be generated by the router as specified in		Public key-pair MUST be generated by the router as specified in
	Section 2. With current specification [RFC5996] when sender needs to		Section 2. To deploy RFA method more widely -
	get the certificate of the receiver, Certificate Request payload
	CERTREQ as specified in [RFC5996] is sent with cert encoding set to
	"Raw RSA Key" and Certification Authority field is empty. The
	receiver of this CERTREQ payload, (currently) uses PKCS #1 encoding
	for the generated RSA Public Key and sends the same in CERT payload
	as Certificate Data with Certificate Encoding set to "Raw RSA Key" as
	described in Section 3.6 of IKEv2 [RFC5996]. Once the public key of
	the sender is received, verification is done with the already
	published/stored fingerprints of the sender. To deploy RFA method
	more widely -
	1. type of public keys supported should be generic; for e.g.,		1. type of public keys supported should be generic; for e.g.,
	support for raw Elliptic Curve public keys and		support for raw Elliptic Curve public keys and
	2. more generic encoding formats should be supported for carrying		2. more generic encoding formats should be supported for carrying
	the raw public keys other than currently defined PKCS #1.		the raw public keys other than currently defined PKCS #1.
	[I-D.kivinen-ipsecme-oob-pubkey] enhances support for other types of		[I-D.kivinen-ipsecme-oob-pubkey] enhances support for other types of
	public keys and also defines new encoding format to carry the public		public keys and also defines new encoding format to carry the public
	key fingerprint in the CERT payload. For RPs to use Router		key fingerprint in the CERT payload. For RPs to use Router
	Fingerprint Authentication in the context of IKEv2 MUST follow the		Fingerprint Authentication in the context of IKEv2 MUST follow the
	encoding format as specified in [I-D.kivinen-ipsecme-oob-pubkey].		encoding format as specified in [I-D.kivinen-ipsecme-oob-pubkey].
	3.1. Impact on the PAD		For RFA, the public key received is in the form of
			SubjectPublicKeyInfo structure of X.509 PKI profile and the Peer
	The Peer Authorization Database (PAD) and the role it plays in peer		Authorization Database (PAD) entry [RFC4301] MUST contain the
	authentication is defined in section 4.4.3 of [RFC4301]. One of the		published fingerprint of the peer.
	functions of the PAD is to provide the authentication data for each
	peer. [RFC4301] supports X.509 certificate or pre-shared secret
	authentication data types but commonly there are also other
	authentication methods implemented (i.e. EAP and raw public keys/
	fingerprints). For RFA, the public key received is in the form of
	SubjectPublicKeyInfo structure of X.509 PKI profile and the PAD entry
	MUST contain the published fingerprint of the peer.
	4. Publishing Router Fingerprints		4. Publishing Router Fingerprints
	The router fingerprint generated is not a secret and can be exchanged		The router fingerprint generated is not a secret and can be exchanged
	out-of-band or can be distributed publicly. Please refer to		out-of-band or can be distributed publicly. Please refer to
	Section 5 for the generic usage and scope of the RFA in routing		Section 5 for the generic usage and scope of the RFA in routing
	environments. In the case of inter-domain routing using EBGP		environments. In the case of inter-domain routing using EBGP
	[RFC4271], if the routers are outside of the SIDR [I-D.ietf-sidr-		[RFC4271], if the routers are outside of the SIDR [I-D.ietf-sidr-
	bgpsec-overview] environment, fingerprint can also be exchanged out-		bgpsec-overview] environment, fingerprint can also be exchanged out-
	of-band through Service Level Agreements (SLAs) at the RP peering		of-band through Service Level Agreements (SLAs) at the RP peering
	points.		points.
	[farrell-decade-ni] defines a "Named Information" identifier, which		[RFC6920] defines a "Named Information" identifier, which provides a
	provides a set of standard ways to use hash function outputs in		set of standard ways to use hash function outputs in names. As there
	names. As there are many ways to publish fingerprints in an		are many ways to publish fingerprints in an unambiguous manner (e.g.,
	unambiguous manner (e.g., as defined in Section 5 of [RFC4572]); on		as defined in Section 5 of [RFC4572]); on the WG consensus, KARP
	the WG consensus, KARP deployments MUST use the method described in		deployments MUST use the method described in [RFC6920] for
	[farrell-decade-ni] for interoperability. A KARP KMP deployment		interoperability. A KARP KMP deployment using router fingerprints
	using router fingerprints need to resort to out-of-band public key		need to resort to out-of-band public key validation procedure to
	validation procedure to verify authenticity of the keys being used.		verify authenticity of the keys being used. The router fingerprints
	The router fingerprints MUST be part of the KMP PAD to validate the		MUST be part of the KMP PAD to validate the public key received in
	public key received in the KMP messages.		the KMP messages.
	5. Scope of Fingerprints usage with RPs		5. Scope of Fingerprints usage with RPs
	The fingerprint method described in this document in general is more		The fingerprint method described in this document in general is more
	suitable for intra domain deployments. This includes KMP usage for		suitable for intra domain deployments. This includes KMP usage for
	e.g., for IBGP [RFC4271] and LDP [RFC5036] peers, where KARP KMP can		e.g., for IBGP [RFC4271] and LDP [RFC5036] peers, where KARP KMP can
	be deployed without having to configure either manual pre-shared keys		be deployed without having to configure either manual pre-shared keys
	to bootstrap KMP or full PKI with trust anchor certificates. Also		to bootstrap KMP or full PKI with trust anchor certificates. Also
	KMPs for group keying RPs can use this method for authenticating the		KMPs for group keying RPs can use this method for authenticating the
	peers in the group. This method also can be potentially used between		peers in the group. This method also can be potentially used between
	skipping to change at page 10, line 20 ¶		skipping to change at page 9, line 26 ¶
	qualified mutual authentication methods are listed in [RFC5998]; of		qualified mutual authentication methods are listed in [RFC5998]; of
	these, a password based methods [RFC4746], [RFC5931], [RFC6124] can		these, a password based methods [RFC4746], [RFC5931], [RFC6124] can
	offer potential EAP alternative for pre-shared key only		offer potential EAP alternative for pre-shared key only
	authentication.		authentication.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[I-D.chunduri-karp-using-ikev2-with-tcp-ao]		[I-D.chunduri-karp-using-ikev2-with-tcp-ao]
	Chunduri, U., Tian, A., and J. Touch, "Using IKEv2 with		Chunduri, U., Tian, A., and J. Touch, "A framework for RPs
	TCP-AO", draft-chunduri-karp-using-ikev2-with-tcp-ao-03		to use IKEv2 KMP", draft-chunduri-karp-using-ikev2-with-
	(work in progress), January 2013.		tcp-ao-05 (work in progress), July 2013.
	[I-D.kivinen-ipsecme-oob-pubkey]		[I-D.kivinen-ipsecme-oob-pubkey]
	Kivinen, T., Wouters, P., and H. Tschofenig, "More Raw		Kivinen, T., Wouters, P., and H. Tschofenig, "More Raw
	Public Keys for IKEv2",		Public Keys for IKEv2", draft-kivinen-ipsecme-oob-
	draft-kivinen-ipsecme-oob-pubkey-03 (work in progress),		pubkey-05 (work in progress), October 2013.
	November 2012.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,		[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
	"Internet Key Exchange Protocol Version 2 (IKEv2)",		"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
	RFC 5996, September 2010.		5996, September 2010.
	11.2. Informative References		11.2. Informative References
	[I-D.farrell-decade-ni]
	Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
	Keraenen, A., and P. Hallam-Baker, "Naming Things with
	Hashes", draft-farrell-decade-ni-10 (work in progress),
	August 2012.
	[I-D.hartman-karp-mrkmp]		[I-D.hartman-karp-mrkmp]
	Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router		Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router
	Key Management Protocol (MaRK)",		Key Management Protocol (MaRK)", draft-hartman-karp-
	draft-hartman-karp-mrkmp-05 (work in progress),		mrkmp-05 (work in progress), September 2012.
	September 2012.
	[I-D.ietf-karp-ops-model]		[I-D.ietf-karp-ops-model]
	Hartman, S. and D. Zhang, "Operations Model for Router		Hartman, S. and D. Zhang, "Operations Model for Router
	Keying", draft-ietf-karp-ops-model-04 (work in progress),		Keying", draft-ietf-karp-ops-model-09 (work in progress),
	October 2012.		October 2013.
	[I-D.ietf-karp-threats-reqs]
	Lebovitz, G., Bhatia, M., and B. Weis, "Keying and
	Authentication for Routing Protocols (KARP) Overview,
	Threats, and Requirements",
	draft-ietf-karp-threats-reqs-07 (work in progress),
	December 2012.
	[I-D.ietf-sidr-bgpsec-overview]		[I-D.ietf-sidr-bgpsec-overview]
	Lepinski, M. and S. Turner, "An Overview of BGPSEC",		Lepinski, M. and S. Turner, "An Overview of BGPSEC",
	draft-ietf-sidr-bgpsec-overview-02 (work in progress),		draft-ietf-sidr-bgpsec-overview-03 (work in progress),
	May 2012.		July 2013.
	[I-D.mahesh-karp-rkmp]		[I-D.mahesh-karp-rkmp]
	Jethanandani, M., Weis, B., Patel, K., Zhang, D., Hartman,		Jethanandani, M., Weis, B., Patel, K., Zhang, D., Hartman,
	S., Chunduri, U., Tian, A., and J. Touch, "Negotiation for		S., Chunduri, U., Tian, A., and J. Touch, "Negotiation for
	Keying Pairwise Routing Protocols in IKEv2",		Keying Pairwise Routing Protocols in IKEv2", draft-mahesh-
	draft-mahesh-karp-rkmp-04 (work in progress),		karp-rkmp-04 (work in progress), February 2013.
	February 2013.
	[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography		[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
	Standards (PKCS) #1: RSA Cryptography Specifications		Standards (PKCS) #1: RSA Cryptography Specifications
	Version 2.1", RFC 3447, February 2003.		Version 2.1", RFC 3447, February 2003.
	[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery		[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
	Protocol (MSDP)", RFC 3618, October 2003.		Protocol (MSDP)", RFC 3618, October 2003.
	[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.		[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
	Levkowetz, "Extensible Authentication Protocol (EAP)",		Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
	RFC 3748, June 2004.		3748, June 2004.
	[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic		[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
	Key Management", BCP 107, RFC 4107, June 2005.		Key Management", BCP 107, RFC 4107, June 2005.
	[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)		[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
	Authentication Protocol", RFC 4252, January 2006.		Authentication Protocol", RFC 4252, January 2006.
	[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)		[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
	Transport Layer Protocol", RFC 4253, January 2006.		Transport Layer Protocol", RFC 4253, January 2006.
	skipping to change at page 12, line 31 ¶		skipping to change at page 11, line 18 ¶
	[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP		[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
	Specification", RFC 5036, October 2007.		Specification", RFC 5036, October 2007.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, May 2008.		(CRL) Profile", RFC 5280, May 2008.
	[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element		[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
	(PCE) Communication Protocol (PCEP)", RFC 5440,		(PCE) Communication Protocol (PCEP)", RFC 5440, March
	March 2009.		2009.
	[RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication		[RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication
	Protocol (EAP) Authentication Using Only a Password",		Protocol (EAP) Authentication Using Only a Password", RFC
	RFC 5931, August 2010.		5931, August 2010.
	[RFC5998] Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension		[RFC5998] Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension
	for EAP-Only Authentication in IKEv2", RFC 5998,		for EAP-Only Authentication in IKEv2", RFC 5998, September
	September 2010.		2010.
	[RFC6124] Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, "An		[RFC6124] Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, "An
	EAP Authentication Method Based on the Encrypted Key		EAP Authentication Method Based on the Encrypted Key
	Exchange (EKE) Protocol", RFC 6124, February 2011.		Exchange (EKE) Protocol", RFC 6124, February 2011.
	[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for		[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for
	Routing Protocols (KARP) Design Guidelines", RFC 6518,		Routing Protocols (KARP) Design Guidelines", RFC 6518,
	February 2012.		February 2012.
	Authors' Addresses		[RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and
			Authentication for Routing Protocols (KARP) Overview,
			Threats, and Requirements", RFC 6862, March 2013.
			[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
			Keranen, A., and P. Hallam-Baker, "Naming Things with
			Hashes", RFC 6920, April 2013.
			Authors' Addresses
	Uma Chunduri		Uma Chunduri
	Ericsson		Ericsson
	300 Holger Way		300 Holger Way
	San Jose, California 95134		San Jose, California 95134
	USA		USA
	Phone: +1 (408) 750-5678		Phone: +1 (408) 750-5678
	Email: uma.chunduri@ericsson.com		Email: uma.chunduri@ericsson.com
	Albert Tian		Albert Tian
	skipping to change at page 13, line 28 ¶		skipping to change at page 12, line 25 ¶
	300 Holger Way		300 Holger Way
	San Jose, California 95134		San Jose, California 95134
	USA		USA
	Phone: +1 (408) 750-5210		Phone: +1 (408) 750-5210
	Email: albert.tian@ericsson.com		Email: albert.tian@ericsson.com
	Ari Keranen		Ari Keranen
	Ericsson		Ericsson
	Hirsalantie 11		Hirsalantie 11
	Jorvas, 02420		Jorvas 02420
	Finland		Finland
	Phone:
	Email: ari.keranen@ericsson.com		Email: ari.keranen@ericsson.com
	Tero Kivinen		Tero Kivinen
	INSIDE Secure		INSIDE Secure
	Eerikinkatu 28		Eerikinkatu 28
	Helsinki, 00180		Helsinki 00180
	Finland		Finland
	Phone:
	Email: kivinen@iki.fi		Email: kivinen@iki.fi
End of changes. 30 change blocks.
	108 lines changed or deleted		77 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/