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

From: Domagoj Premec <[email-masked]>
Date: Wed, 20 Oct 2010 16:30:20 +0200

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: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Laganier, Julien
>> Sent: Thursday, September 23, 2010 9:31 PM
>> To: [email-masked]
>> Cc: [email-masked]
>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mext
>>
>

---

From: jouni korhonen <[email-masked]>
Date: Thu, 21 Oct 2010 00:09:34 +0300

Hi Damagoj,

THanks for the thorough review! See my responses inline:

> incoming packets protected with the existing SA?

The HA would accept incoming packets until the MN contacts the HAC, re-establishes the SA and as a result the HAC pushes new SA information to the HA.

> of the new SA is initialized to zero.

Right, sequence numbers fate-share the SA. We'll clarify this.

> Should it also cover the IPv4 subnet?

Good point. We actually have discussed this to some extent. There was the issue whether it should be possible for the MN to be e.g. at home on IPv4 but on foreign link on IPv6 in a case the MN is attached to a dual-stack link..

> messages and couldn't find one.

Ok. Got the point. We should actually just use request/response as the messages are the same and only matched using the identifier in the container.

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

In a case the message exchange fails immediately, the HAC would response (section 5.8, step 2) with error status code and auth. The message would not contain mn-rand, hac-rand, auth-method in that case.

Note that it seems the current text is not really clear on this, nor completely inline regarding the use of MNAuth-Done, status code etc.
> MHAuth-Done? It would be good to clarify this.

See above.

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

Like a corporate treats all its employers as the same? You can have a "group" without individuals using realm only.

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

Three dots you mean? It is a left over, or actually lazyness from my side not to point properly to RFC4282 or completing the BNF for NAI.

> If it is present only in the final message, what is the usage for the

Good point. We'll remove it.

> I'm not sure what the msg-header refers to.

Good catch. The start of msg-header is supposed to mean the start of auth header.

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

Ok.

> Is this needed given that there is a Length field in the message

It is not needed.

> maybe a different formulation would help avoid such misunderstanding?

See my comment for Section 3.. The current text is not the best regarding MNAuth-Done.

> calculation of the auth signature in message 3?

Could be.. I'll let the more security biased authors to express their opinion ;)

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

In a case authentication fails immediately, the response would contain only status & auth.

> in line with the usage in this section.

Again, see the comment for Section 3.

> When exactly would the HAC echo the mn-rand and what is the use case

mn-rand is echoed always after message 2.. in case of PSK.

> sa-scope and ciphersuite-list may be optional here? If repeating the

no.

> good to include a note clarifying that. What about repeating the

Ok.

> sa-scope, sa-data and ciphersuite should be mandatory in the

Yes. Actually, some parameters shown in the square brackets do not seem to be in sync with the rest of the text anymore. Meaning those parameters has to match for naming used otherwhere in the text.

> s/MHAuth-Auth/MHAuth-Init?

Ack.

> 4. Please consider revising the text so that it follows the message

Ack.

> used only in the final message?

See the comment for Section 3.

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

The last response can indicate an error and in that case those are not needed.

> Mobile IPv6 service port number?

Responses are sent to the port from the request. The service port is defined only as where the HA listens for UDP packets.

> s/or a, an encrypted/or an encrypted

Ack.

> two SPIs per the MN-HA mobility session?

Hmm.. yes. Good catch. We'll reword the text accordingly.

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

Ack.

> binding management messages must be protected.

Ack.

> the user data packet format section in case of encrypted user traffic.

Ack. Will add another pointer to RFC4304.

- Jouni