Subject: [Mip6] WG LC: I-D draft-ietf-mip6-rfc4285bis-00.txt

From: Basavaraj Patil <[email-masked]>
Date: Mon, 20 Aug 2007 15:19:40 -0500

Hello,

This is a WG last call for the I-D: Authentication Protocol for Mobile
IPv6 <draft-ietf-mip6-rfc4285bis-00.txt>

This I-D revises RFC4285 and corrects the key-length issue which has
been discussed in the past.

Please send your comments by Sept 5th, 07 to the mailing list or the
authors. 

-Raj

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

---

From: Thomas Narten <[email-masked]>
Date: Wed, 22 Aug 2007 12:21:49 -0400

Very quick comment. Where is the changes section outlining what has
changed relative to the RFC it replaces? That is the first question I
had...

Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 27 Aug 2007 15:18:24 +0200

Basavaraj Patil wrote:
> Hello,
> 
> This is a WG last call for the I-D: Authentication Protocol for 
> Mobile IPv6 <draft-ietf-mip6-rfc4285bis-00.txt>
> 

Hi Raj, here are some comments on this draft.

Overall, I support it and its advancement (I have some comments for
improvement), but I don't believe it on the Standards Track; mainly
because it has an established alternative and widely deployed which
scales.

> The authentication option specified in Section 5 is applicable in 
> certain types of networks that have the following characteristics:
> 
> - Networks in which the authentication of the MN for network access 
> is done by an authentication server in the home network via the home 
> agent.  The security association is established by the network 
> operator (provisioning methods)

I wouldn't use the term "security association" because that's IPsec.

> The security association is created via an out-of-band mechanism or 
> by non Mobile IPv6 signaling.

Mobile IPv6 signalling doesn't establish SAs anyways.

If the SA is established somehow then it's sufficient to use AH (of
IPsec) protection, no need of authopt Mobility Message Authentication
Data.  It doesn't gain anything at all, and IPsec AH code is already
there everywhere.

> IKEv2 as a technology has yet to reach maturity status and widespread
>  implementations needed for commercial deployments on a large scale.
>  At the time of this writing [IKEv2-REF] is yet to be published as an
>  RFC.

Just FYI, IKEv2 is RFC4306 since December 2005, references will have to
be updated.

> MIP6 signaling which relies on IKE as the primary means for setting 
> up an SA between the MN and HA requires more signaling messages 
> compared with the use of an authentication option carried in the 
> BU/BAck messages.

I'm not sure I understand this.

IKE establishes keys.

Authopt by this draft doesn't.

If keys are pre-established (either pre-shared, or via out of band
means, or via 'provisioning') then authopt authentication takes 
precisely same number of message-on-wire as IPsec AH - it's the BU/BAck.

I think you're in one sense comparing IKEv2 vs the 'provisioning'
mechanism while at the same time comparing authopt authentication vs AH
authentication, drawing false conclusions.

> The authentication option described in Section 5 may be used by the 
> mobile node to transfer authentication data when the mobile node and
>  the home agent are utilizing a mobility SPI (a number in the range 
> [0-4294967296] used to index into the shared-key based mobility 
> security associations). to index between multiple mobility security 
> associations.

I think this paragraph is difficult to understand, the dot before 'to'
seems redundant.

But I agree with the intent and it describes the needed behaviour.

> This section defines a message authentication mobility option that 
> may be used to secure Binding Update and Binding Acknowledgement 
> messages.

 From an implementation perspective, the authopt could be used for MPD,
for BErr and for BReq as well, I think it should.  Otherwise IPsec AH is
needed for these messages.

One wouldn't want BU/BAck auth'ed with authopt and BErr/BReq/MPD auth'ed
with IPsec AH, right?

> Option Length:
> 
> 
> 
> 8-bit unsigned integer, representing the length in octets of the 
> Sub-type, mobility Security Parameter Index (SPI) and Authentication 
> Data fields.
[...]
> Alignment requirements :
> 
> 
> 
> The alignment requirement for this option is 4n + 1.

(1) Where and when to pad in order to reach this alignment?
(2) Shouldn't the option length be expressed in 4n octets instead of
     simply octets?  That's what many other IPv6 users do.
(3) _if_ precisely 96bits of message digest are used then the length is
     constand and no need of alignment requirements specification, or
     ellipsis in message descriptio - just fill constants in.  Right?

> The authentication algorithm is HMAC_SHA1.

I think it should be at least SHA2 or SHA256 because of known
weaknesses.

I think choice should be offered to operators so they can choose which 
algo to use depending on various factors such as security strength 
needed, local legislation, existing implementation, and so on.

Do you know that SHA1 has security issues?

> If the Timestamp option is used for replay protection as defined in 
> Section 6, the mobility security association includes a "close 
> enough" field to account for clock drift.

I wouldn't recommend to anyone caring about security to use timestamps
for replay protection.  The other alternative is better (seq numbers).

> The Mobile Node or Home Agent receiving this option MUST verify the 
> authentication data in the option.

How and what to verify?  This should be specified.  Namely the HA
receiving a BU should hash the received packet and compare the 96bits
with the ones in the recv'd auth header.

Also what happens if the HA doesn't support the type of the 
authentication required in the packet?  (eg only supports MN-HA option, 
not MN-AAA option).  Should it discard?  Send BErr?

> If authentication fails, the Home Agent MUST send BA with Status Code
>  MIPV6-AUTH-FAIL.

Authenticated BAck or non-authenticated?

> If the Home Agent does not have shared-key based mobility SA, Home
> Agent MUST discard the BU.  The Home Agent MAY log such events.

I agree.

>    If mobility SPI has the well-known value HMAC_SHA1_SPI, then
>    hash_fn() is HMAC_SHA1.

What other than the (weak) SHA1 can the SPI contain?  Is there another 
digest algorithm?

>    In case of authentication failure, the Home Agent MUST send a Binding
>    Acknowledgement with status code MIPV6-AUTH-FAIL to the Mobile Node,
>    if a shared-key based mobility security association to be used
>    between Mobile Node and Home Agent for authentication exists.  If
>    there is no shared-key based mobility security association, HA drops
>    the Binding Update.  HA may log the message for administrative
>    action.
> 
>    Upon receiving a Binding Acknowledgement with status code MIPV6-AUTH-
>    FAIL, the Mobile Node SHOULD stop sending new Binding Updates to the
>    Home Agent.

If the BAck is not protected itself with a authopt then isn't there a 
strong risk of DoS attack on MN?  Attacker sends BAck MIPv6-AUTH-FAIL to 
all MNs, they don't authenticate it, and thus they stop sending BUs to 
their HAs.

Thanks,

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Aug 2007 06:40:06 -0700

Hi Alex,

Responding to a few comments that caught my eye....

> because it has an established alternative and widely deployed which

I think the target for this document is Informational.

>> - Networks in which the authentication of the MN for network access is 
>> done by an authentication server in the home network via the home 

No this is not correct. Security association is a generic term. When you 
want to associate it with IPsec, you have to explicitly say "IPsec SA". 
RFC 2002 (which was standardized in 1996) already used the term 
"mobility security association".

> (1) Where and when to pad in order to reach this alignment?

Before the Type field.

>     simply octets?  That's what many other IPv6 users do.

For all mobility options, the length field is in terms of octets. No 
reason to change that.

>     ellipsis in message descriptio - just fill constants in.  Right?

The alignment requirement comes from the presence of a 32-bit integer 
field, the Mobility SPI, in the option and the desire to have this field 
fall on the 4 byte boundary.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 27 Aug 2007 15:51:09 +0200

> I think the target for this document is Informational.

I agree then.

> "mobility security association".

Ok, I didn't know that.

But I'm not sure what other type of "security association" is 
implemented, I mean I have only seen IPsec SAs.

What would the AuthOpt SA look like?  What is the length of the key?

Would a AuthOpt SA database be standardized? (like the IPsec SA database).

>> (1) Where and when to pad in order to reach this alignment?

Why not picturing it?  A simple Pad0 there.

> For all mobility options, the length field is in terms of octets. No 

Ok.

> fall on the 4 byte boundary.

But do you agree that the length field always contains the same value 
(103 decimal)?  There's no variable-length subfield here, right?

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Aug 2007 07:12:54 -0700

> What would the AuthOpt SA look like?  What is the length of the key?

The draft already describes this

    The shared-key based mobility security association between Mobile
    Node and Home Agent used within this specification consists of a
    mobility SPI, a key, an authentication algorithm and the replay
    protection mechanism in use.  The mobility SPI is a number in range
    [0-4294967296], where the range [0-255] is reserved.  The key
    consists of an arbitrary value and is 20 octets in length.  The
    authentication algorithm is HMAC_SHA1.

> Would a AuthOpt SA database be standardized? (like the IPsec SA database).

I don't see a need for that.

> Why not picturing it?  A simple Pad0 there.

You never do that. Lets say before adding the authentication option, the 
length of the packet is 121 bytes, then you would add the authentication 
option without any padding. If it is 118 bytes, you would add 3 bytes of 
padding before the authentication option.

>> field, the Mobility SPI, in the option and the desire to have this 
>> field fall on the 4 byte boundary.
> 

True, but RFC 3775 says all mobility options have a type and length 
fields. :) See section 6.2.1 in RFC 3775. And it makes processing on the 
receiving side easy.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 27 Aug 2007 16:38:44 +0200

> authentication algorithm is HMAC_SHA1.

Look, when I read "mobility security association" I can understand the
text better.

But in at least one place the draft talks about "shared-key based
security association", other place "shared mobility security
association" and means "shared-key based mobility security association".

This is very confusing.  The fix to this can be very easy.

Ok.

> You never do that. Lets say before adding the authentication option,
> the length of the packet is 121 bytes, then you would add the
> authentication option without any padding. If it is 118 bytes, you
> would add 3 bytes of padding before the authentication option.

If you pad _before_ this option header then the alignment shouldn't be
specified at all by this option.

I think above you're talking about the overall Mobility Header alignment
requirement, and this is already specified, no need to put it here.

>>>> (3) _if_ precisely 96bits of message digest are used then the
>>>> length is constand and no need of alignment requirements
>>>> specification, or ellipsis in message descriptio - just fill
>>>> constants in.  Right?
>>> 
>>> The alignment requirement comes from the presence of a 32-bit
>>> integer field, the Mobility SPI, in the option and the desire to
>>> have this field fall on the 4 byte boundary.
>> 
>> But do you agree that the length field always contains the same
>> value (103 decimal)?  There's no variable-length subfield here,
>> right?
> 
> fields. :) See section 6.2.1 in RFC 3775. And it makes processing on
> the receiving side easy.

Right... makes sense... maybe it is sufficient to just say that there is
a length field and its contents is constant 103 decimal, no?

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Aug 2007 07:46:06 -0700

> requirement, and this is already specified, no need to put it here.

No. When you specify an alignment requirement for an option, it points 
to what padding might be required *before* the option. Each option would 
have its own alignment requirement (some none).

> a length field and its contents is constant 103 decimal, no?

But why would you hard code something in the spec? No need to.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 27 Aug 2007 17:18:06 +0200

> have its own alignment requirement (some none).

We have a different understanding here... I always see the padding 
_after_ the option such that to reach an alignment limit, especially 
when there are variable length fields.

But you're right... it could be equivalent... depends who reads and how.

> But why would you hard code something in the spec? No need to.

Some specs I read hardcode the len fields and this is much easier for 
implementation.

You _do_ hardcode IANA numbers in specs, right?

Alex

---

From: <[email-masked]>
Date: Wed, 29 Aug 2007 08:01:47 +0200

Hi,

I read the rfc4285bis and have minor comments on it. I have editorials
and other comments mixed up.. sorry about that. Anyway, my conclusion
is that the I-D needs some more work to be OK..

Quick references to not so editorial issues are in
 o section 3.1 about SPIs
 o section 5.1 about key length and auth algorithm

-----

Abstract

  >IPsec is specified as the means of securing signaling messages
  >between the Mobile Node and Home agent for Mobile IPv6 (MIPv6).

   o .,$s/Home agent/Home Agent/g
     There are many places to do the same change throughout the 
     document. So no more further mentions of this.
   o s/Mobile IPv6 (MIPv6)\./Mobile IPv6\.

  >MIPv6 signalling messages that are secured include the Binding

   o s/MIPv6/Mobile IPv6

  >Updates and Acknowledgement messages used for managing the bindings
  >between a Mobile Node and its Home Agent.  This document proposes an
  >alternate method for securing MIPv6 signaling messages between a

   o s/MIPv6/Mobile IPv6

  >Mobile Nodes and Home Agents.  The alternate method defined here
  >conists of a MIPv6-specific authentication option that can be added

   o s/conist/consists
   o s/MIPv6/Mobile IPv6

  >to MIPv6 signalling messages.

   o s/MIPv6/Mobile IPv6

1.  Introduction

  >The base Mobile IPv6 specification [RFC3775] specifies the signaling

   o s/Mobile IPv6/Mobile IPv6 (MIPv6)

  >between the Mobile Node and Home agent to be secured by the IPsec

   o s/Mobile Node/Mobile Node (MN)
   o s/Home agent/Home Agent (HA)

  >Acknowldegement messages (between MN-HA) are secured with the

   o MN-HA?  what about "between MN and HA" ?

1.1.  Applicability Statement

  >network operator.  In cdma network deployments this information can

   o .,$s/cdma/CDMA
   o Expand CDMA on the first use

  >- Network deployments in which not all mobile nodes and home agents

   o .,$s/mobile node/Mobile Node/g    there are same change many times
     throughout the documents so it is mentioned only here.

  >have IKEv2 implementations and support for the integration of IKEv2

   o Reference to IKEv2.. and maybe expand on the first use.

  >commercial deployments on a large scale.  At the time of this writing
  >[IKEv2-REF] is yet to be published as an RFC.  Hence from a practical
  >perspective that operators face, IKEv2 is not yet capable of
  >addressing the immediate need for MIP6 deployment.

   o The above statement is not really true anymore -- ref RFC4306
     and I would also reference to RFC4877

  >between the mobile node and the authentication server (AAA Home) is

   o what about changing "AAA Home" to "home AAA server" ?

  >mechanisms to renew the security association (between MN and AAA
  >Home) when needed.

   o Same about the AAA than above. Or then define it as AAAH already
     in this paragraph

  >signaling messages sent over such interfaces.  MIP6 signaling which

   o s/MIP6/MIPv6   or just use Mobile IPv6
     Whatever is used it should ne consistent throughout the document.
     Now MIP6, MIPv6 and Mobile IPv6 are used in a nice mixture

  >an authentication option carried in the BU/BAck messages.

   o s/Back/BA

2.  Overview

  >guarantee such protection (for instance, like in 3gpp2 networks),

   o s/3gpp2/3GPP2

Section 3.1

   o Mobility SPI -- can this be different from MN to HA and from
     HA to MN? It is not stated/defined anywhere.. From the current
     text one gets the impression that the SPI is the same on  both
     directions
   o The reserved SPI range should be described here as well
   o Expand SPI here on the first use.

Section 4.
 
  >(BU) and Binding Acknowledgement (BA) messages are used in the

   o BU & BA are already defined..

   o Figure 1 -- MN-ID is not defined nor used anywhere else in the
     document. Why not replacing it with MN-NAI as it is what the
     figure is trying to say..

  >security associations). to index between multiple mobility security

   o Remove the "to index between multiple mobility security
     associations."

5.  Mobility message authentication option

  >If both MN-HA and MN-AAA authentication options are present, MN-HA

   o Expand MN-HA and MN-AAA on the first use.

  >the Sub-type, mobility Security Parameter Index (SPI) and
  >Authentication Data fields.

   o s/mobility Security Parameter Index (SPI)/mobility SPI

5.1.  MN-HA authentication mobility option

  >[0-4294967296], where the range [0-255] is reserved.  The key

   o rather "shared-key" than just "key"?

  >authentication algorithm is HMAC_SHA1.  The replay protection

   o MN-HA option has Mobility SPI, so why the key length and the
     used algorithm are hardcoded here? Should those be selected &
     defined based on the SPI rather than hardcoding them here?

  >mechanism may use the Sequence number as specified in [RFC3775] or

   o s/Sequence/sequence  ?

  >the option as defined in Section 6.  If the Timestamp option is used

   o s/option/Timestamp option

  >This MUST be the last option in a message with mobility header if it

   o s/This/The MN-HA authentication option

  >Authentication Data = First (96, HMAC_SHA1(MN-HA Shared key, Mobility
  >Data))

   o The same what was stated above.. Why not use SPI to select key
     lengths and algorithms?

  >The first 96 bits from the MAC result are used as the Authentication
  >Data field.

   o This is stated already earlier.
   o Rather define Mobility Header(MH) as

     message data starting from the mobility header upto and including
     the Mobility SPI value of the Mobility message authentication
option

5.2.  MN-AAA authentication mobility option

  >corresponding response MUST include the Mobile-Home Authentication
  >option, and MUST NOT include the Mobile-AAA Authentication option.

   o s/Mobile-Home Authentication/MN-HA authentication
   o s/Mobile-AAA Authenticatio/MN-AAA authentication

  >MAC_Mobility Data = SHA1(care-of address | home address | MH Data)

   o Earlier MH Data was expressed as Mobility Header(MH)

  >mobility SPI field of this option.

   o s/this/the Mobility message authentication

5.3.  Authentication Failure Detection at the Mobile Node

  >there is no shared-key based mobility security association, HA drops

   o s/drops/MUST silently discard

6.  Mobility message replay protection option

  >after the binding entry has been removed.  The Home Agent does the
 
   o s/binding/binding cache

Section 10:

   o [MN_Ident]  -> RFC4283
   o [IKEv2-REF] -> RFC4306
   o [whyauth]   -> -04.txt

Cheers,
	Jouni

> -----Original Message-----
> From: Basavaraj Patil [mailto:[email-masked]] 
> Sent: Monday, August 20, 2007 11:20 PM
> To: Mobile IPv6 Mailing List
> Cc: [email-masked]; Kent Leung (kleung); [email-masked]
> Subject: [Mip6] WG LC: I-D draft-ietf-mip6-rfc4285bis-00.txt
> 
> 
> 
> Hello,
> 
> This I-D revises RFC4285 and corrects the key-length issue 
> which has been discussed in the past.
> 
> Please send your comments by Sept 5th, 07 to the mailing list 
> or the authors. 
> 
> -Raj
> 
>