[Mipshop] FW: Discussion on Proposed Changes to draft-ietf-mipshop-handover-key-00.txt

["Vijay Devarapalli" <[e-mail]>]

Trying again.

> -----Original Message-----
> From: James Kempf [mailto:[e-mail]]
> Sent: Friday, July 13, 2007 9:55 AM
> To: [e-mail]
> Subject: Discussion on Proposed Changes to
draft-ietf-mipshop-handover-
> key-00.txt
> 
> Folks,
> 
> I'd like to start a thread on two changes I'd like to propose to the
SEND
> keys draft.
> 
> Earlier this year, an issue came up involving the use of the RSA
> authentication key to perform encryption. This is prohibited by RFC
3972.
> In
> general, use of an RSA key for both encryption and authentication is
> discouraged because it is possible that an attacker could compromise
> authentiation by selectively encrypting text. This requires that the
> attacker be able to encrypt text of its choosing. As the RSA SEND
> authentication key is used for encryption in the SEND keys draft, the
only
> material encrypted is controlled by the access router, so the access
> router
> would need to be compromised for this attack to succeed. If the access
> router is compromised, the impact could be considerably more severe
than
> just on FMIP security, of course.
> 
> However, I've been working with Prof. John Mitchell of Stanford and
Arnab
> Roy, his student, who have done much work on proving correctness of
> security
> protocols, on this issue. The problem is that proving correctness is
> difficult if the same key is used for both operations. In addition,
> although
> the use of the key for two purposes isn't such a problem for RSA as
used
> in
> SEND keys, the design is fragile and might be a problem if the
conditions
> around the design change. For example, if algorithm agility is
introduced
> into SEND (something being discussed for CGA-EXT), another algorithm
might
> not have the same properties.
> 
> Therefore, the first change I'd like to propose is that instead of
reusing
> the SEND authentication key, the MN sends a separate RSA key to the AR
and
> the AR uses that key to encrypt the shared key. In order to
accommodate
> future algorithm agility and preserve simplicity, the text should be
> written
> so that the algorithm type used is the same as whatever algorithm is
used
> for SEND. The CGA construction is unchanged, it uses the
authentication
> key,
> and the shared key is tied to the CGA via the authentication on the
> PrRtSol.
> This seems like the simplest possible change.
> 
> Secondly, the current SEND keys draft uses RS/RA in order to perform
the
> key
> provisioning. As the FMIP protocol is currently written, a MN does not
> need
> to use RS/RA if the next hop router information can be obtained using
> PrRtSol/PrRtAdv, though it can. So the MN would need to perform an
> additional message exchange in order to obtain the handover key. The
> additional exchange is not tied to handover, so it does not impact
> handover
> performance, but it will be extra message traffic on the link.
> 
> Therefore, I'd like to propose that the SEND key exchange be moved to
the
> PrRtSol/PrRtAdv. Note that this means both messages must be protected
by
> SEND and that the PrRtSol must have as its source address the CGA for
the
> MN
> and the PrRtAdv must have as its source address the CGA for the AR,
> calculated using the router's certified public key.
> 
> One possible objection to this is that it is not clear at this point
> whether
> the PrRtXXX messages will be deployed even if FMIP is. They depend on
> either
> manually or automatically configuring the access point to access
router
> mappings into the access routers, which might not be something that
access
> network providers want to do. FMIP can be used without these messages,
> even
> though it is specified with them. If that is the case, RS/RA can still
be
> used. Perhaps this could be written as MAY, in order to accommodate
this
> case.
> 
> I'd like to run the discussion for a couple weeks, then when the draft
> gate
> opens after IETF I'll publish the new draft.
> 
> Comments?
> 
>                         jak


_______________________________________________
Mipshop mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mipshop