Re: [MEXT] Reviews of draft-korhonen-mext-mip6-altsec

[Domagoj Premec <[e-mail]>]

Hi everyone,

This is my review of the mip6-altsec draft. I think the draft is in a
good shape and I haven't found any issues that would affect the
overall concept. The comments I have should serve mainly as means to
identify places where some additional explanation is needed to tighten
the text up.

I find that the way the (DS)MIP6 interacts with the IPsec is complex
and difficult to grasp and implement and in this regard this is an
interesting draft and I believe it should be progressed further. I
have also played around with a MIP6 implementation based on this
draft, I was able to get it up and running quickly and it performed
without any problems.

Here are my comments...

> 4.3.  Security Association Management
>   ...
>   The HA may want the MN to re-establish the SA even if the existing SA
>   is still valid.  The HA can indicate this to the MN using a dedicated
>   Status Code in a BA (value set to REINIT_SA_WITH_HAC).

After responding with REINIT_SA_WITH_HAC, will the HA accept the
incoming packets protected with the existing SA?

> Sequence numbers:
>
>      A monotonically increasing unsigned sequence number used in all
>      protected packets exchanged between the MN and the HA in the same
>      direction.

The definition it is not clear if the scope of the sequence number is
the SA or the session with the HA. Please clarify that in the case
when an existing SA gets replaced with a new one, the sequence number
of the new SA is initialized to zero.

>4.4.  Bootstrapping of Additional Mobile IPv6 Parameters
>...
>   Home Link Prefix:
>
>      Concerns the IPv6 Home link prefix and the associated prefix
>      length.

Should it also cover the IPv4 subnet?

> 5.3.  Request-Response Message Exchange

This section introduces the MHAuth-Init and MHAuth-Done messages. I
couldn't find the TV-header indicating the message type, i.e.
something like "msg-type : MHAuth-Init". If the protocol does not
contain the indication of the message type, then I would suggest
talking simply in terms of first/last request/response message and not
using the terms like MHAuth-Init/Done. At least for me it was
confusing as I kept looking for the definition of the MHAuth-Init/Done
messages and couldn't find one.

>  The first request message - MHAuth-Init - (i.e. the Identifier is 1)
>   MUST always contain at least the following parameters:
>
>      MN-Identity - See Section 5.5.1.
>      Authentication Method - See Section 5.5.2.

Is mn-rand optional? Sections 5.8 and 5.9 give impression that it is
always required?

Related to the usage of the MHAuth-Done, the draft gives the
impression that the MHAuth-Init request is always responded with the
MHAuth-Init response. Can the HAC respond to the MHAuth-Init request
with the, for example "MHAuth-Done(status=internal error)"? Does the
MN need to acknowledge such MHAuth-Done by replying with another
MHAuth-Done? It would be good to clarify this.

>  5.5.1.  Mobile Node Identifier
...
>      nai = username
>          | "@" realm
>          | username "@" realm

What is the use case for the realm without the user name?

The definition of the NAI is followed by an ellipsis, a typo?

> 5.5.4.  Status Code
>
>   The "status-code" MUST only be present in the response message that
>   ends the request-response message exchange.

If it is present only in the final message, what is the usage for the
value 100 - Continue?

> 5.5.5.  Message Authenticator
>
>   The "auth" header contains data used for authentication purposes.  It
>   MUST be the last TV-header in the message and calculated over the
>   whole message till the start of the "msg-header":

Could you provide a pointer to the "msg-header" definition? At least
I'm not sure what the msg-header refers to.

> 5.5.6.  Retry After
>
>      retry-after = "retry-after" ":" rfc1123-date CRLF

Maybe a pointer to RFC 2616 or some other document for usage?

> 5.5.7.  End of Message Content
>
>      end-of-message = 2CRLF

Is this needed given that there is a Length field in the message
container header?

> 5.8.  Authentication of the Mobile Node
...
>   The
>   MHAuth-Done messages are used to deal with error situations.

This may sound like the MHAuth-Done are not used in a success case,
maybe a different formulation would help avoid such misunderstanding?

>   1)  Request/MHAuth-Init: (MN -> HAC)
>          mn-id, mn-rand, auth-method=psk

It looks like the parameters from the MHAuth-Init request are not
protected. Why is the auth header omitted here, or would it
security-wise make sense to include these parameters in the
calculation of the auth signature in message 3?

>   2)  Response/MHAuth-Init: (MN <- HAC)
>          [mn-rand, hac-rand, auth-method=psk, [status],] auth

Is the auth-method optional? According to section 5.3, it is a
mandatory parameter?

What is status, is this the status-code TV header from section 5.5.4?
According to section 5.5.4, it may appear only in the "response
message that ends the request-response message exchange", which is not
in line with the usage in this section.

When exactly would the HAC echo the mn-rand and what is the use case
behind this?

>   3)  Request/MHAuth-Done: (MN -> HAC)
>          mn-rand, hac-rand, sa-scope, ciphersuite-list, auth

sa-scope and ciphersuite-list may be optional here? If repeating the
mn-rand and the hac-rand here makes sense security-wise, it would be
good to include a note clarifying that. What about repeating the
mn-id?

>   4)  Response/MHAuth-Done: (MN <- HAC)
>          [sa-scope, sa-data, ciphersuite, bootstrapping-data,] mn-rand,
>          hac-rand, status, auth

sa-scope, sa-data and ciphersuite should be mandatory in the
successful MHAuth-Done?

>   The MN verifies the received MAC and the consistency of the
>   identities, nonces, and ciphersuite parameters transmitted in MHAuth-
>   Auth.

s/MHAuth-Auth/MHAuth-Init?

It seems that the last paragraph in section 5.8 is about the MN
sending the MHAuth-Done, which is step 3 whereas the preceding
paragraph talks about the HAC sending the MHAuth-Done, which is step
4. Please consider revising the text so that it follows the message
sequence from fig. 4.

>5.9.  Extensible Authentication Protocol Methods
...
>   2)  Response/MHAuth-Init: (MN <- HAC)
>          [auth-method=eap, eap, [status,]] auth

Auth method and eap payload are not optional? Status is supposed to be
used only in the final message?

>   6)  Response/MHAuth-Done: (MN <- HAC)
>          [sa-scope, sa-data, ciphersuite, bootstrapping-data,] eap,
>          status, auth

sa-scope, sa-data and ciphersuite need to be mandatory here?

> 6.  Mobile Node to Home Agent communication
>...
>   The
>   Mobile IPv6 service MAY use any ephemeral port number as the UDP
>   source port, and MUST use the Mobile IPv6 service port number
>   (HALTSEC) as the UDP destination port.

Is the response sent to the source port from the request or to the
Mobile IPv6 service port number?

s/or a, an encrypted/or an encrypted

>   There is always only one SPI per MN-HA mobility session and the same
>   SPI is used for all types of protected packets independent of the
>   direction.

When the current SA gets replaced with the new SA, isn't there some
period of overlap where both SAs are active and hence there would be
two SPIs per the MN-HA mobility session?

s/as treated as data packets /are treated as data packets

> 6.3.  Binding Management Message Formats

>  For a SPI value of 0 (zero) that indicates an unprotected
>   packet, the Padding, Pad Length, Next Header and ICV fields MUST NOT
>   be present.

This sentence probably needs to be removed from this section as the
binding management messages must be protected.

The encoding for the Payload Data field in not explained. Please add
some text/pointer as to how this field is encoded. The same applies to
the user data packet format section in case of encrypted user traffic.

Regards,
Domagoj


>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Laganier, Julien
>> Sent: Thursday, September 23, 2010 9:31 PM
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: [MEXT] Reviews of draft-korhonen-mext-mip6-altsec
>>
>> Folks,
>>
>> The chairs have received a request from the authors of
>> http://tools.ietf.org/html/draft-korhonen-mext-mip6-altsec
>> that their draft be adopted as one of the WG deliverables for
>> our "alternative security mechanisms" work item.
>>
>> Before we go ahead with this, the chairs would like to
>> solicit at least three thorough review of the document to
>> ensure that the has an adequate understanding of the proposal
>> and its implications.
>>
>> Please support the WG process by volunteering as a reviewer.
>>
>> --julien & marcelo
>> _______________________________________________
>> MEXT mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mext
>>
>