[secdir] Anyone got a spare hour?

[Stephen Farrell <[e-mail]>]

If you do, today or tomorrow, and are in the mood, I'd
appreciate if you could take a look at a discuss point
([1], point #1) I have on a document [2] where I've not
had the time yet to go through it in enough detail and
the WG are meeting Thursday and understandably would like
to progress it before then.

The situation is a mobile node ("MN") talking to a bit
of MIP infrastructure (a "HAC"), over a TLS session,
with TLS-server-endpoint channel bindings. (There's a
separate issue about how they describe the TLS session
but that's being addressed already.)

Their MN authentication then goes:

"
    MN                                                      HAC
     |                                                       |
     | Request/MHAuth-Init (...)                             |
     |------------------------------------------------------>|
     |                                                       |
     |                            Response/MHAuth-Init (...) |
     |<------------------------------------------------------|
     |                                                       |
     | Request/MHAuth-Done (...)                             |
     |------------------------------------------------------>|
     |                                                       |
     |                            Response/MHAuth-Done (...) |
     |<------------------------------------------------------|
     |                                                       |

      Figure 4: Authentication of the Mobile Node Using Shared Secrets

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

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

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

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

    Where:

       auth = HMAC-SHA256(PSK, msg-octets | CB-octets)

    The length "mn-rand", "hac-rand" is 32 octets.  Note that "|"
    indicates concatenation and optional parameters are shown in square
    brackets [..].  The square brackets can be nested.

    The shared secret PSK can be variable length. 'msg-octets' includes
    all payload parameters of the respective message to be signed except
    the 'auth' payload.  CB-octets is the channel binding input to the
    auth calculation that is the "TLS-server-endpoint" channel binding
    type.
"

My concern is that there may be reflection attacks, or similar
but I've not had the time yet to get down to the nitty-gritty.
The attack I've in mind is an MN connecting to the HAC, getting
a variant of message 2 and replaying that as message 3. I might
want to hold the discuss to get them to add some directional
thing in any case, but would really appreciate if someone can
delve a bit into how these messages would look on the wire to
see if this is a practical attack or just being careful for
the future.

And since I saw the above problem, I'm a bit concerned there
might be more issues, so more eyeballs would be good for that
in any case.

Feel free to reply on or off list if you do have time to look
at this.

Thanks in advance,
S.

[1] 
https://datatracker.ietf.org/doc/draft-ietf-mext-mip6-tls/ballot/#stephen-farrell
[2] https://datatracker.ietf.org/doc/draft-ietf-mext-mip6-tls/