Re: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap

["Dan Harkins" <dharkins@lounge.org>]

  Hi Joe,

  As I mentioned at the mic during the meeting at IETF69
draft-zorn-radius-keywrap is not really very (crypto-)agile and I
think with some minor modifications could be made more so. For example:

  - do not require that Message-Authentication-Code MUST be present
    if Keying-Material is present. SIV is a much preferrable key
    wrapping technique than RFC3394 and if SIV was specified in the
    enc-type of Keying-Material then Message-Authentication-Code would
    be redundant. Please say that if enc-type is RFC3394 then
    Message-Authentication-Code MUST also be present. Other enc-types
    can mandate it or not as needed.

  - do not require Mac-Randomizer if Message-Authentication-Code is
    present. The reason a deterministic authenticated encryption scheme
    like RFC3394 can provide what amounts to probabilistic authenticated
    encryption is because what it's wrapping is, itself, random. The
    further addition of randomness is unnecessary.

  - the IV is not necessary. Key wrapping (RFC3394 or even SIV in its
    key wrapping varient) is deterministic. RFC3394 has a default IV which
    is used to determine whether the unwrapping was successful or not but
    that does not need to be communicated. draft-zorn-radius-keywrap even
    says that if RFC3394 is being used as the enc-type then the IV MUST
    be A6A6A6A6A6A6A6A6. That serves no useful purpose.

  - not everyone is comfortable with massive covert channels like KEK ID
    and KM ID. I suggest making them optional and using a bit it the
    reserved field to indicate their presense or absense.

  Crypto-agility isn't just the ability to substitute one algorithm for
another, it should include the jettisoning any unnecessary baggage that
might've been appropriate (or required) for one algorithm if it's not
appropriate (or required) for another. Some of this stuff might be
needed if you're using RFC3394 and some stuff might be useful for
whatever your existing implementation is using them for but I don't think
I should be forced to add covert channels, repeat known information
(A6A6A6A6...), or unnecessarily integrity protect an already integrity
protected message. It surely isn't (crypto-)agile to force me to.

  thanks,

  Dan.

On Mon, July 23, 2007 9:03 am, Joseph Salowey (jsalowey) wrote:
>
>
> SECURITY SERVICES
>
> 2. Proposals MUST support the negotiation of cryptographic algorithms
> for per-packet integrity/authentication protection.
> Support for confidentiality of entire RADIUS packets is OPTIONAL.
> However, proposals MUST support the negotiation of algorithms for
> encryption (sometimes referred to as "hiding") of RADIUS attributes.
> If possible, it is desirable for proposals to provide for the encryption
> of existing attributes.  This includes existing "hidden"
> attributes as well as attributes (such as location attributes) that
> require confidentiality.
>
> Included in negotiation techniques are "hint and consent" mechanisms
> where the NAS provides a list of algorithms and the server selects one.
>
> [Joe] Algorithms within the proposal are identified so they can be
> replaced.  The client can specify the algorithm it wishes the server to
> use.
>
>
> 3. Proposals MUST support replay protection.  The existing mechanisms
> for replay protection are considered adequate and should be maintained.
>
> [Joe] Existing replay protection mechanisms are maintained
>
> 4. Crypto-agility solutions MUST specify mandatory-to-implement
> algorithms for each mechanism.
>
> [Joe] Mandatory to implement algorithms are specified (AES-CBC,
> AES-Keywrap, HMAC-SHA1)
>
> BACKWARD COMPATIBILITY
>
> 5. Solutions to the problem MUST demonstrate backward compatibility with
> existing RADIUS implementations.  That is, a crypto-agility solution
> needs to be able to send packets that a legacy RADIUS client or server
> will receive and process successfully.  Similarly, a crypto-agility
> solution needs to be capable of receiving and processing packets from a
> legacy RADIUS client or server.
>
> [Joe]  The proposal requires the use of new RADIUS attributes.  All
> other aspects of the RADIUS protocol can remain the same, so backward
> compatibility is possible.  However it is important to note that if
> stronger that current security algorithms are required then backwards
> compatibility is not possible.
>
> 6. Crypto-agility solutions MUST avoid security compromise, even in
> situations where the existing cryptographic algorithms utilized by
> RADIUS implementations are shown to be weak enough to provide little or
> no security (e.g. in event of compromise of the "legacy" RADIUS shared
> secret). Included in this would be protection against bidding down
> attacks.
>
> [Joe] Depending upon the selection of the key the new protection can be
> completely separate from the existing protection.  The selection of the
> key is currently a deployment choice.
>
>
> INTEROPERABILITY AND CHANGE CONTROL
>
> 7. Proposals MUST indicate a willingness to cede change control to the
> IETF.
>
> [Joe] Change control can be cede. An informational RFC may be published
> to document existing implementations.
>
> 8. Crypto-agility solutions MUST be interoperable between independent
> implementations based purely on the information provided in the
> specification.
>
> [Joe] Interoperable implementations exist based on this specification.
> These implementations use VSAs instead of standard attributes.
>
> SCOPE OF WORK
>
> 9. Crypto-agility solutions MUST apply to all RADIUS packet types,
> including Access-Request, Challenge, Reject & Accept,
> Accounting-Request/Response, and CoA/Disconnect messages.
>
> [Joe] The attributes described can be added to any of these mechanisms.
>
> 10. Proposals MUST include a Diameter compatibility section, although it
> is expected that the work will occur purely within RADIUS or in the
> transport, and therefore does not affect message data that is exchanged
> with Diameter.
>
> [Joe] A Diameter compatibility section will need to be added.
>
> 11. Crypto-agility solutions SHOULD NOT require fundamental changes to
> The RADIUS operational model, such as the introduction of new commands
> Or maintenance of state on the RADIUS server.  Similarly, a proposal
> Should focus on the crypto-agility problem and nothing else.  For
> example, proposals should not require new attribute formats or include
> definition of new RADIUS services.  Unless modified, the restrictions in
> the RADEXT WG charter apply.
>
> [Joe] This solution works well with the existing implementations.  It
> does not require major changes to the RADIUS protocol.  In particular it
> does not necessarily introduce new "session" state maintenance
> requirements on the server.
>
> Note that for the purposes of this work, the RADEXT WG charter
> Restriction against definition of "new security mechanisms" should be
> interpreted as prohibiting changes to the basic RADIUS packet format
> (e.g. headers), but permits new crypto-algorithms to be substituted For
> use in existing security mechanisms.
>
> [Joe] This is what the proposal does.  It is very close to existing
> RADIUS protection mechanisms requiring minimal change to existing
> implementations.
>
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>