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

[jouni korhonen <[e-mail]>]

Hi Damagoj,

THanks for the thorough review! See my responses inline:


On Oct 20, 2010, at 5:30 PM, Domagoj Premec wrote:

> 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?

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.


> 
>> 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.


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

> 
>> 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?

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..

> 
>> 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.

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.


> 
>> 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?

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.
> 
> 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.

See above.


> 
>> 5.5.1.  Mobile Node Identifier
> ...
>>     nai = username
>>         | "@" realm
>>         | username "@" realm
> 
> 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.


> 
>> 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?

Good point. We'll remove it.

> 
>> 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.

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


> 
>> 5.5.6.  Retry After
>> 
>>     retry-after = "retry-after" ":" rfc1123-date CRLF
> 
> Maybe a pointer to RFC 2616 or some other document for usage?

Ok.


> 
>> 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?

It is not needed.

> 
>> 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?

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

> 
>>  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?

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

> 
>>  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?
> 

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


> 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.

Again, see the comment for Section 3.


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

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

> 
>>  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

no.

> 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?

Ok.

> 
>>  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?

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.

> 
>>  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?

Ack.


> 
> 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.

Ack.


> 
>> 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?

See the comment for Section 3.

> 
>>  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?

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

> 
>> 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?

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.

> 
>>  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?

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

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

Ack.

> 
>> 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.

Ack.

> 
> 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.

Ack. Will add another pointer to RFC4304.

- Jouni

> 
> 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
>>> 
>> 
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext