draft-ietf-mext-mip6-tls-04.txt   draft-ietf-mext-mip6-tls-05.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: September 13, 2012 Nokia Expires: September 29, 2012 Nokia
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
D. Kroeselberg D. Kroeselberg
Siemens Siemens
March 12, 2012 March 28, 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-04.txt draft-ietf-mext-mip6-tls-05.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 September 13, 2012. This Internet-Draft will expire on September 29, 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 9 skipping to change at page 3, line 9
5.6.5. CipherSuites and Ciphersuite-to-Algorithm Mapping . . 17 5.6.5. CipherSuites and Ciphersuite-to-Algorithm Mapping . . 17
5.7. Mobile IPv6 Bootstrapping Parameters . . . . . . . . . . . 18 5.7. Mobile IPv6 Bootstrapping Parameters . . . . . . . . . . . 18
5.7.1. Home Agent Address . . . . . . . . . . . . . . . . . . 18 5.7.1. Home Agent Address . . . . . . . . . . . . . . . . . . 18
5.7.2. Mobile IPv6 Service Port Number . . . . . . . . . . . 18 5.7.2. Mobile IPv6 Service Port Number . . . . . . . . . . . 18
5.7.3. Home Addresses and Home Network Prefix . . . . . . . . 18 5.7.3. Home Addresses and Home Network Prefix . . . . . . . . 18
5.7.4. DNS Server . . . . . . . . . . . . . . . . . . . . . . 19 5.7.4. DNS Server . . . . . . . . . . . . . . . . . . . . . . 19
5.8. Authentication of the Mobile Node . . . . . . . . . . . . 19 5.8. Authentication of the Mobile Node . . . . . . . . . . . . 19
5.9. Extensible Authentication Protocol Methods . . . . . . . . 21 5.9. Extensible Authentication Protocol Methods . . . . . . . . 21
6. Mobile Node to Home Agent communication . . . . . . . . . . . 23 6. Mobile Node to Home Agent communication . . . . . . . . . . . 23
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2. PType and Security Parameter Index . . . . . . . . . . . . 24 6.2. PType and Security Parameter Index . . . . . . . . . . . . 25
6.3. Binding Management Message Formats . . . . . . . . . . . . 25 6.3. Binding Management Message Formats . . . . . . . . . . . . 25
6.4. Reverse Tunneled User Data Packet Formats . . . . . . . . 27 6.4. Reverse Tunneled User Data Packet Formats . . . . . . . . 27
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
skipping to change at page 19, line 36 skipping to change at page 19, line 36
through channel binding based on [RFC5056] and on the channel binding through channel binding based on [RFC5056] and on the channel binding
type 'tls-server-endpoint' described in [RFC5929]. As a result of type 'tls-server-endpoint' described in [RFC5929]. As a result of
the channel binding type, this method can only be used with TLS the channel binding type, this method can only be used with TLS
ciphersuites that use server certificates and the Certificate ciphersuites that use server certificates and the Certificate
handshake message. For example, TLS ciphersuites based on PSK or handshake message. For example, TLS ciphersuites based on PSK or
anonymous authentication cannot be used. anonymous authentication cannot be used.
The authentication exchange MUST be performed through the encrypted The authentication exchange MUST be performed through the encrypted
TLS tunnel. It performs mutual authentication between the MN and the TLS tunnel. It performs mutual authentication between the MN and the
HAC based on a pre-shared key (PSK) or based on an EAP-method (see HAC based on a pre-shared key (PSK) or based on an EAP-method (see
Section 5.9). The PSK protocol is described in this section. It Section 5.9). Note that a HAC MUST NOT allow MNs to renegotiate TLS
sessions. The PSK protocol is described in this section. It
consists of the message exchanges (MHAuth-Init, MHAuth-Mid, MHAuth- consists of the message exchanges (MHAuth-Init, MHAuth-Mid, MHAuth-
Done) in which both sides exchange nonces and their identities, and Done) in which both sides exchange nonces and their identities, and
compute and exchange a message authenticator 'auth' over the compute and exchange a message authenticator 'auth' over the
previously exchanged values, keyed with the pre-shared key. The previously exchanged values, keyed with the pre-shared key. The
MHAuth-Done messages are used to deal with error situations. Key MHAuth-Done messages are used to deal with error situations. Key
binding with the TLS tunnel is ensured by channel binding of the type binding with the TLS tunnel is ensured by channel binding of the type
"tls-server-endpoint" as described by [RFC5929] where the hash of the "tls-server-endpoint" as described by [RFC5929] where the hash of the
TLS server certificate serves as input to the 'auth' calculation of TLS server certificate serves as input to the 'auth' calculation of
the MHAuth messages. the MHAuth messages.
skipping to change at page 20, line 38 skipping to change at page 20, line 39
2) Response/MHAuth-Init: (MN <- HAC) 2) Response/MHAuth-Init: (MN <- HAC)
[mn-rand, hac-rand, auth-method=psk, [status],] auth [mn-rand, hac-rand, auth-method=psk, [status],] auth
3) Request/MHAuth-Done: (MN -> HAC) 3) Request/MHAuth-Done: (MN -> HAC)
mn-rand, hac-rand, sa-scope, ciphersuite-list, auth mn-rand, hac-rand, sa-scope, ciphersuite-list, auth
4) Response/MHAuth-Done: (MN <- HAC) 4) Response/MHAuth-Done: (MN <- HAC)
[sa-scope, sa-data, ciphersuite, bootstrapping-data,] mn-rand, [sa-scope, sa-data, ciphersuite, bootstrapping-data,] mn-rand,
hac-rand, status, auth hac-rand, status, auth
Where: Where 'auth' for MN -> HAC direction is:
auth = HMAC-SHA256(PSK, msg-octets | CB-octets) auth = HMAC-SHA256(PSK, "MN" | msg-octets | CB-octets)
Where 'auth' for MN <- HAC direction is:
auth = HMAC-SHA256(PSK, "HAC" | msg-octets | CB-octets)
In the above "MN" is 2 ASCII characters without null termination and
"HAC" is 3 2 ASCII characters without null termination.
The length "mn-rand", "hac-rand" is 32 octets. Note that "|" The length "mn-rand", "hac-rand" is 32 octets. Note that "|"
indicates concatenation and optional parameters are shown in square indicates concatenation and optional parameters are shown in square
brackets [..]. The square brackets can be nested. brackets [..]. The square brackets can be nested.
The shared secret PSK can be variable length. 'msg-octets' includes The shared secret PSK can be variable length. 'msg-octets' includes
all payload parameters of the respective message to be signed except all payload parameters of the respective message to be signed except
the 'auth' payload. CB-octets is the channel binding input to the the 'auth' payload. CB-octets is the channel binding input to the
auth calculation that is the "TLS-server-endpoint" channel binding auth calculation that is the "TLS-server-endpoint" channel binding
type. The content and algorithm (only required for the "TLS-server- type. The content and algorithm (only required for the "TLS-server-
skipping to change at page 23, line 12 skipping to change at page 23, line 12
MHAuth-Mid exchange is repeated as many times as needed by the MHAuth-Mid exchange is repeated as many times as needed by the
used EAP-method. used EAP-method.
5) Request/MHAuth-Done: (MN -> HAC) 5) Request/MHAuth-Done: (MN -> HAC)
sa-scope, ciphersuite-list, eap, auth sa-scope, ciphersuite-list, eap, auth
6) Response/MHAuth-Done: (MN <- HAC) 6) Response/MHAuth-Done: (MN <- HAC)
[sa-scope, sa-data, ciphersuite, bootstrapping-data,] eap, [sa-scope, sa-data, ciphersuite, bootstrapping-data,] eap,
status, auth status, auth
Where: Where 'auth' for MN -> HAC direction is:
auth = HMAC-SHA256(shared-key, msg-octets | CB-octets) auth = HMAC-SHA256(shared-key, "MN" | msg-octets | CB-octets)
Where 'auth' for MN <- HAC direction is:
auth = HMAC-SHA256(shared-key, "HAC" | msg-octets | CB-octets)
In the above "MN" is 2 ASCII characters without null termination and
"HAC" is 3 2 ASCII characters without null termination.
In MHAuth-Init and MHAuth-Mid messages, shared-key is set to "1". If In MHAuth-Init and MHAuth-Mid messages, shared-key is set to "1". If
the EAP-method is key-deriving and creates a shared MSK key as a side the EAP-method is key-deriving and creates a shared MSK key as a side
effect of Authentication shared-key MUST be the MSK in all MHAuth- effect of Authentication shared-key MUST be the MSK in all MHAuth-
Done messages. This MSK MUST NOT be used for any other purpose. In Done messages. This MSK MUST NOT be used for any other purpose. In
case the EAP method does not generate an MSK key, shared-key is set case the EAP method does not generate an MSK key, shared-key is set
to "1". to "1".
'msg-octets' includes all payload parameters of the respective 'msg-octets' includes all payload parameters of the respective
message to be signed except the 'auth' payload. CB-octets is the message to be signed except the 'auth' payload. CB-octets is the
skipping to change at page 35, line 25 skipping to change at page 35, line 25
different keys are used). different keys are used).
9.4. AAA Interworking 9.4. AAA Interworking
The AAA backend infrastructure interworking is not defined in this The AAA backend infrastructure interworking is not defined in this
document and therefore out-of-scope. document and therefore out-of-scope.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Pasi Eronen, Domagoj Premec, Julien The authors would like to thank Pasi Eronen, Domagoj Premec, Julien
Laganier, Jari Arkko and Christian Bauer for their comments. Laganier, Jari Arkko, Stephen Farrell, Peter Saint-Andre and
Christian Bauer for their comments.
11. References 11. References
11.1. Normative References 11.1. Normative References
[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.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998. ESP and AH", RFC 2404, November 1998.
 End of changes. 11 change blocks. 
11 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/