Subject: [MSEC] RE: Some comments on http://ftp.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-00.txt

From: "Ignjatic, Dragan" <[email-masked]>
Date: Wed, 13 Jul 2005 16:02:22 -0700

Thanks Mark,
We will try to be more explicit about Initiator's options here.
There is a number of ways how this can (securely) be done and we should
list the acceptable methods.

Regards,
Dragan

-----Original Message-----
From: Mark Baugher [mailto:[email-masked]] 
Sent: July 13, 2005 3:26 PM
To: Lakshminath Dondeti; Francois Audet
Cc: 'Cullen Jennings'; Ignjatic, Dragan; Dan Wing;
[email-masked]; Dave Oran; Flemming S Andreasen
Subject: Re: Some comments on
http://ftp.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-00.txt

Francois, Lakshminath
    I think what we want to define for MIKEY is the ability of the 
responder to hand the initiator a key.  This is done in rsa-r and it is 
done in RFC 3547 (GDOI).  RFC 3830 (MIKEY) initiators hand the key to 
the responder, not vice versa, so I see why you want to change that 
when talking to bridges, controllers, etc.

    Existing msec RFCs also discuss the following issue that you raise:

>   "When using the RSA-R mode, the Responder may turn out to be 
> different
>    from who the Initiator sent the MIKEY message to.  It is the
>    responsibility of the Initiator to verify that the identity of the
>    Responder is acceptable if it changes from the intended Responder,
>
>
>
> Ignjatic, et al.         Expires January 8, 2006               [Page 
> 10]
> 

> Internet-Draft                 MIKEY-RSA-R                     July 
> 2005
>
>
>    based on its policy, and to take appropriate action based on the
>    outcome.  In some cases, it could be appropriate to accept any
>    Responder's identity; in other cases, a blacklist or a whitelist
may
>    be appropriate."

I don't see why we are going here and admitting antispam mechanisms in 
the key establishment.  I would expect that the initiator will 
establish a connection with the responder, which has a cryptographic 
identity.  What if the message gets redirected or (more likely) 
intercepted and another entity responds?  We discuss this in RFC 3547 
and also is RFC 4046:

"Alternatively, the sender may forward rekey messages on behalf of the
    GCKS when it uses a credential mechanism that supports delegation.
    Thus, it is possible for the sender, or other members, to source
    keying material (TPKs encrypted in the Group KEK) as it sources
    multicast or unicast data.  As mentioned above, the rekey message
can
    be sent using unicast or multicast delivery.  Upon receipt of a TPK
    (as part of a Data SA) via a rekey message or a registration
protocol
    exchange, the member's group key management functional block will
    provide the new or updated security association (SA) to the data
    security protocol.  This protects the data sent from sender to
    receiver."

In other words, rsa-r can be used by a credentialing mechanism that 
supports delegation or some other method that allows the initiator to 
determine (1) that the responder is authorized to respond (perhaps for 
an entity with a different identity) and (2) the initiator is 
authorized to communicate with the particular responder, or delegated 
responder.

The way it's written now, it just sounds like something that could be 
done very insecurely.  It says that the initiator is responsible but 
does not give a clue how it could be done.

Mark
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec