Re: [HOKEY] consensus call: key delivery security protocol

If AAA-proxy compromise is not part of our threat model, then all parties 
are securely authenticated and keying material remains undisclosed to 
non-trusted parties.  The draft-housley-aaa-key-mgmt doesn't say to whom 
the keying material must remain confidential, or that only the two 
endpoints can know a key.

Sure, a proxy can be compromised and misbehave, but so can a AAA server.

The cryptographic protocol academic in me cringes to say that, but I don't 
see any practical way to avoid it.  We need to trust the AAA 
infrastructure.  We can certainly document the concerns associated with a 
hop-by-hop protocol in the security considerations section.

--
t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  eng.umd.edu/~tcc
adjunct professor, electrical engineering, university of maryland

On Tue, 7 Aug 2007, Yoshihiro Ohba wrote:

> I was taking vacation and sorry for delayed response.
>
> How does option #1 with hop-by-hop security satisfy
> draft-housley-aaa-key-mgmt-09.txt, especially "Authenticate all
> parties" and "Keying material confidentiality and integrity"
> requirements?
>
> Regards,
> Yoshihiro Ohba
>
>
>
> On Mon, Jul 23, 2007 at 01:32:36PM -0400, Charles Clancy wrote:
>> Related issue: #28
>>
>> The current key distribution document describes protocols that require a
>> shared key between the server and third party.  According to RFC 4107,
>> we are required to specify how those keys are provisioned.  The result
>> was 3 options:
>>
>> #1: convert the current protocol into one that uses hop-by-hop security
>> with channel bindings based on AAA
>>
>> #2: define a protocol to provision keys, as necessary, between AAA
>> servers and any remote AAA client that needs a pairwise key for
>> end-to-end security
>>
>> #3: use something like cross-realm Kerberos to provide the necessary
>> cryptographics to improve upon hop-by-hop security
>>
>> An initial hum eliminated option #2.  A vote for options #1 and #3
>> yielded 23 in favor of #1 and 11 in favor of #3.  This email is to
>> confirm the consensus in the room during the meeting.
>>
>> Please comment by August 2.
>>
>> --
>> t. charles clancy, ph.d.  <>  tcc@umd.edu  <>  eng.umd.edu/~tcc
>> adjunct professor, electrical engineering, university of maryland
>>
>> _______________________________________________
>> HOKEY mailing list
>> HOKEY@ietf.org
>> https://www1.ietf.org/mailman/listinfo/hokey
>>
>

_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www1.ietf.org/mailman/listinfo/hokey