Subject: RE: [Mip6] FW: I-D ACTION:draft-vidya-rfc4285-security-analysis-00.txt

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 21 Dec 2006 01:04:30 -0500

I find that this analysis is based on some assumptions that are quite
outdated. For example use of static NAI in the identifier option and the
use of MN-AAA key to bootstrap MN-HA key. These are old assumptions
regarding how the industry is trying to use RFC 4285.

In WiMAX NWG for example, the NAI is set to pseudoNAI to do identity
hiding. The MN-AAA AE is not used at all. The MN-HA AE is used with
MN-HA key which is bootstrapped from EAP keying framework (EMSK ->
MIP-RK -> ...).  The MN-HA SA is indexed by the Mobility SPI.

Regarding the key length issue (which we found to be the ONLY real
issue), we have submitted an update:

http://tools.ietf.org/wg/mip6/draft-patel-mip6-rfc4285bis-00.txt

-Kuntal

> -----Original Message-----
> From: Narayanan, Vidya [mailto:[email-masked]]
> Sent: Wednesday, December 20, 2006 11:33 AM
> To: [email-masked]
> Subject: [Mip6] FW: I-D ACTION:draft-vidya-rfc4285-security-analysis-
> 00.txt
> 
> All,
> A number of people have asked about the security concerns with
RFC4285.
> This draft provides an analysis of that. Please send any comments to
me.
> 
> 
> Thanks,
> Vidya
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, December 19, 2006 12:50 PM
> > To: [email-masked]
> > Subject: I-D ACTION:draft-vidya-rfc4285-security-analysis-00.txt
> >
> > A New Internet-Draft is available from the on-line
> > Internet-Drafts directories.
> >
> >
> > 	Title		: Security Analysis of RFC4285
> > 	Author(s)	: V. Narayanan
> > 	Filename	: draft-vidya-rfc4285-security-analysis-00.txt
> > 	Pages		: 9
> > 	Date		: 2006-12-19
> >
> >   RFC4285 [1] provides a means of using pre-shared key (PSK) based
or
> >    AAA-based credentials for Mobile IPv6.  It is intended to provide
a
> >    light-weight security mechanism for MIP6 signaling.  However, the
> >    protocol comes with a set of security issues that are worth
looking
> >    at.  This document presents a security analysis on the protocol.
> >
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-vidya-rfc4285-securi
> ty-analysis-00.txt
> >
> > To remove yourself from the I-D Announcement list, send a message to
> > [email-masked] with the word unsubscribe in
> > the body of
> > the message.
> > You can also visit
> > https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the
> > username "anonymous" and a password of your e-mail address. After
> > logging in, type "cd internet-drafts" and then
> > "get draft-vidya-rfc4285-security-analysis-00.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > 	[email-masked].
> > In the body type:
> > 	"FILE
> > /internet-drafts/draft-vidya-rfc4285-security-analysis-00.txt".
> >
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant
> > mail readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "Mohamed Khalil" <[email-masked]>
Date: Thu, 21 Dec 2006 08:53:30 -0600

even if the MN-AAA is used, it will be used as follows:
when the SA is not established yet at the initialization phase, the
MN-AAA auth extension could be used and the spi in this case will be SPI
= HMAC_SHA1_SPI, which indicate that the SHA1 is the hashing alg to be
used. Once, the the MN-AAA authentication is done, a shared secret key
will be generated, and a unique SPI is assigned to the MN to be used to
index the created SA for future transactions.

Once we are done with the init phase, the SPI will be used to select the
SA which has been established before. All future transactions will use
the SHA1 as a hashing alg.  

-----Original Message-----
From: Chowdhury, Kuntal [mailto:[email-masked]] 
Sent: Thursday, December 21, 2006 12:05 AM
To: [email-masked]
Subject: RE: [Mip6] FW: I-D
ACTION:draft-vidya-rfc4285-security-analysis-00.txt

-Kuntal

RFC4285.
me.
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> >
> >
or
a
looking

> > [email-masked] with the word unsubscribe in the body 
> > of the message.
> > You can also visit
> > logging in, type "cd internet-drafts" and then "get 
> > draft-vidya-rfc4285-security-analysis-00.txt".
> >
> > http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > 	a MIME-compliant mail reader.  Different MIME-compliant mail 
> > readers

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 21 Dec 2006 15:38:06 -0800

Hi Kuntal,

The draft only covers an analysis of the work done at the IETF
(particularly, just RFC4285). There is no work on EMSK-based MIP keys at
the IETF at the moment. While using temporary IDs and removing the need
for using the MN-AAA key directly for protection will remove a few of
the concerns, other concerns still exist (the ability to do protected ID
exchanges, changes to temporary IDs to prevent tracking, etc.). Also,
such methods introduce their own set of concerns that would be a
separate discussion not under this scope. 

Hope that helps. 

Vidya

> Sent: Wednesday, December 20, 2006 10:05 PM
> To: [email-masked]
> Subject: RE: [Mip6] FW: 
> I-DACTION:draft-vidya-rfc4285-security-analysis-00.txt 
> 
> I find that this analysis is based on some assumptions that 
> are quite outdated. For example use of static NAI in the 
> identifier option and the use of MN-AAA key to bootstrap 
> MN-HA key. These are old assumptions regarding how the 
> industry is trying to use RFC 4285.
> 
> In WiMAX NWG for example, the NAI is set to pseudoNAI to do 
> identity hiding. The MN-AAA AE is not used at all. The MN-HA 
> AE is used with MN-HA key which is bootstrapped from EAP 
> keying framework (EMSK -> MIP-RK -> ...).  The MN-HA SA is 
> indexed by the Mobility SPI.
> 
> Regarding the key length issue (which we found to be the ONLY 
> real issue), we have submitted an update:
> 
> > Subject: [Mip6] FW: I-D

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 21 Dec 2006 16:13:41 -0800

Hi Mohamed,
The RFC currently states that the SPI is an index to the SA and
subsequently states that the SPI is fixed. A fixed SPI cannot be an
index to the SA. In reality, the SPI that the document refers to is just
pointing to the algorithm and not the SA. Also, the term SPI has some
baggage with the IPsec usage - it appears that a similar definition of
SPI as in IPsec is used in the document, even though, it really doesn't
use it the same way.  

Those are the things that this draft is pointing out. 

Regards,
Vidya

> From: Mohamed Khalil [mailto:[email-masked]] 
> Sent: Thursday, December 21, 2006 6:54 AM
> To: Chowdhury, Kuntal; [email-masked]
> when the SA is not established yet at the initialization 
> phase, the MN-AAA auth extension could be used and the spi in 
> this case will be SPI = HMAC_SHA1_SPI, which indicate that 
> the SHA1 is the hashing alg to be used. Once, the the MN-AAA 
> authentication is done, a shared secret key will be 
> generated, and a unique SPI is assigned to the MN to be used 
> to index the created SA for future transactions.
> 
> Once we are done with the init phase, the SPI will be used to 
> select the SA which has been established before. All future 
> transactions will use the SHA1 as a hashing alg.  
> 
>