< draft-ietf-mext-mip6-tls-03.txt		draft-ietf-mext-mip6-tls-04.txt >
	Mobility Extensions (MEXT) J. Korhonen, Ed.		Mobility Extensions (MEXT) J. Korhonen, Ed.
	Internet-Draft Nokia Siemens Networks		Internet-Draft Nokia Siemens Networks
	Intended status: Experimental B. Patil		Intended status: Experimental B. Patil
	Expires: August 18, 2012 Nokia		Expires: September 13, 2012 Nokia
	H. Tschofenig		H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	D. Kroeselberg		D. Kroeselberg
	Siemens		Siemens
	February 15, 2012		March 12, 2012
	Transport Layer Security-based Mobile IPv6 Security Framework for Mobile		Transport Layer Security-based Mobile IPv6 Security Framework for Mobile
	Node to Home Agent Communication		Node to Home Agent Communication
	draft-ietf-mext-mip6-tls-03.txt		draft-ietf-mext-mip6-tls-04.txt
	Abstract		Abstract
	Mobile IPv6 signaling between a mobile node and its home agent is		Mobile IPv6 signaling between a mobile node and its home agent is
	secured using IPsec. The security association between a mobile node		secured using IPsec. The security association between a mobile node
	and the home agent is established using IKEv1 or IKEv2. The security		and the home agent is established using IKEv1 or IKEv2. The security
	model specified for Mobile IPv6, which relies on IKE/IPsec, requires		model specified for Mobile IPv6, which relies on IKE/IPsec, requires
	interaction between the Mobile IPv6 protocol component and the IKE/		interaction between the Mobile IPv6 protocol component and the IKE/
	IPsec module of the IP stack. This document proposes an alternate		IPsec module of the IP stack. This document proposes an alternate
	security framework for Mobile IPv6 and Dual-Stack Mobile IPv6, which		security framework for Mobile IPv6 and Dual-Stack Mobile IPv6, which
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	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 August 18, 2012.		This Internet-Draft will expire on September 13, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 3, line 22 ¶		skipping to change at page 3, line 22 ¶
	7. Route Optimization . . . . . . . . . . . . . . . . . . . . . . 28		7. Route Optimization . . . . . . . . . . . . . . . . . . . . . . 28
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
	8.1. New Registry: Packet Type . . . . . . . . . . . . . . . . 29		8.1. New Registry: Packet Type . . . . . . . . . . . . . . . . 29
	8.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 29		8.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 29
	8.3. Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 29		8.3. Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 29
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 30		9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
	9.1. Discovery of the HAC . . . . . . . . . . . . . . . . . . . 30		9.1. Discovery of the HAC . . . . . . . . . . . . . . . . . . . 30
	9.2. Authentication and Key Exchange executed between the		9.2. Authentication and Key Exchange executed between the
	MN and the HAC . . . . . . . . . . . . . . . . . . . . . . 30		MN and the HAC . . . . . . . . . . . . . . . . . . . . . . 30
	9.3. Protection of MN and HA Communication . . . . . . . . . . 33		9.3. Protection of MN and HA Communication . . . . . . . . . . 33
	9.4. AAA Interworking . . . . . . . . . . . . . . . . . . . . . 34		9.4. AAA Interworking . . . . . . . . . . . . . . . . . . . . . 35
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 35		11.1. Normative References . . . . . . . . . . . . . . . . . . . 35
	11.2. Informative References . . . . . . . . . . . . . . . . . . 35		11.2. Informative References . . . . . . . . . . . . . . . . . . 36
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
	1. Introduction		1. Introduction
	Mobile IPv6 [RFC6275] signaling, and optionally user traffic, between		Mobile IPv6 [RFC6275] signaling, and optionally user traffic, between
	a mobile node (MN) and home agent (HA) are secured by IPsec		a mobile node (MN) and home agent (HA) are secured by IPsec
	[RFC4301]. The current Mobile IPv6 security architecture is		[RFC4301]. The current Mobile IPv6 security architecture is
	specified in [RFC3776] and [RFC4877]. This security model requires a		specified in [RFC3776] and [RFC4877]. This security model requires a
	tight coupling between the Mobile IPv6 protocol part and the IKE(v2)/		tight coupling between the Mobile IPv6 protocol part and the IKE(v2)/
	IPsec part of the IP stack. Client implementation experience has		IPsec part of the IP stack. Client implementation experience has
	shown that the use of IKE(v2)/IPsec with Mobile IPv6 is fairly		shown that the use of IKE(v2)/IPsec with Mobile IPv6 is fairly
	skipping to change at page 30, line 34 ¶		skipping to change at page 30, line 34 ¶
	to the scope of this document.		to the scope of this document.
	9.2. Authentication and Key Exchange executed between the MN and the		9.2. Authentication and Key Exchange executed between the MN and the
	HAC		HAC
	This document describes a simple authentication and MN-HA SA		This document describes a simple authentication and MN-HA SA
	negotiation exchange over TLS. The TLS procedures remain unchanged;		negotiation exchange over TLS. The TLS procedures remain unchanged;
	however, channel binding is provided.		however, channel binding is provided.
	Authentication: Server-side certificate based authentication MUST be		Authentication: Server-side certificate based authentication MUST be
	performed using TLS 1.2 [RFC5246].		performed using TLS 1.2 [RFC5246]. The MN MUST verify the HAC's
			TLS server certificate, using either subjectAltName extension
			[RFC5280] dNSName identities as described in [RFC6125] or
			subjectAltName iPAddress identities. In case of iPAddress
			identities the MN MUST check the IP address of the TLS connection
			against these iPAddress identities and SHOULD reject the
			connection if none of the iPAddress identities match the
			connection. In case of dNSName identities the rules and
			guidelines defined in [RFC6125] apply here, with the following
			considerations:
			* Support for DNS-ID identifier type (the dNSName identity in the
			subjectAltName extension) is REQUIRED in the HAC and the MN TLS
			implementations.
			* DNS names in the HAC server certificates MUST NOT contain the
			wildcard character "*".
			* The CN-ID MUST NOT be used for authentication within the rules
			described in [RFC6125].
			* The MN MUST set its "reference identifier" to the DNS name of
			the HAC.
	The client-side authentication may depend on the specific		The client-side authentication may depend on the specific
	deployment and is therefore not mandated. Note that TLS-PSK		deployment and is therefore not mandated. Note that TLS-PSK
	[RFC4279] cannot be used in conjunction with the methods described		[RFC4279] cannot be used in conjunction with the methods described
	in section 5.8 and 5.9 of this document due to the limitations of		in section 5.8 and 5.9 of this document due to the limitations of
	the channel binding type used.		the channel binding type used.
	Through the protected TLS tunnel, an additional authentication		Through the protected TLS tunnel, an additional authentication
	exchange is performed that provides client-side or mutual		exchange is performed that provides client-side or mutual
	authentication and exchanges SA parameters and optional		authentication and exchanges SA parameters and optional
	skipping to change at page 35, line 42 ¶		skipping to change at page 36, line 20 ¶
	[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure		[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
	Channels", RFC 5056, November 2007.		Channels", RFC 5056, November 2007.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	[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, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
			[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
			Housley, R., and W. Polk, "Internet X.509 Public Key
			Infrastructure Certificate and Certificate Revocation List
			(CRL) Profile", RFC 5280, May 2008.
	[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings		[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
	for TLS", RFC 5929, July 2010.		for TLS", RFC 5929, July 2010.
	[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support		[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
	in IPv6", RFC 6275, July 2011.		in IPv6", RFC 6275, July 2011.
	11.2. Informative References		11.2. Informative References
	[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,		[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
	August 1980.		August 1980.
	skipping to change at page 37, line 5 ¶		skipping to change at page 37, line 31 ¶
	[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and		[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
	Routers", RFC 5555, June 2009.		Routers", RFC 5555, June 2009.
	[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised",		[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised",
	RFC 5944, November 2010.		RFC 5944, November 2010.
	[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 5996, September 2010.		RFC 5996, September 2010.
			[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
			Verification of Domain-Based Application Service Identity
			within Internet Public Key Infrastructure Using X.509
			(PKIX) Certificates in the Context of Transport Layer
			Security (TLS)", RFC 6125, March 2011.
	Authors' Addresses		Authors' Addresses
	Jouni Korhonen (editor)		Jouni Korhonen (editor)
	Nokia Siemens Networks		Nokia Siemens Networks
	Linnoitustie 6		Linnoitustie 6
	Espoo FIN-02600		Espoo FIN-02600
	Finland		Finland
	Email: jouni.nospam@gmail.com		Email: jouni.nospam@gmail.com
	Basavaraj Patil		Basavaraj Patil
	Nokia		Nokia
	6021 Connection Drive		6021 Connection Drive
	Irving, TX 75039		Irving, TX 75039
	USA		USA
	Email: basavaraj.patil@nokia.com		Email: basavaraj.patil@nokia.com
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
End of changes. 10 change blocks.
	10 lines changed or deleted		40 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/