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

[Yoshihiro Ohba <[e-mail]>]

I think that this issue is fundamental.  Please see my comment inline.

On Wed, Aug 08, 2007 at 02:51:16PM -0400, T. Charles Clancy wrote:
> 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 issue is not about compromise of an entity that generates or uses
the keying material (any key distribution cannot securely work if such
compromise happens).  The issue is whether it is acceptable for the
keying material to be seen by an entity that does not generate or use
it in order for the key distribution to work.  In the case of HOKEY,
such an entity is typically a AAA proxy that may sit on the key
distribution path between an authenticator and a HOKEY server or
between a HOKEY server and a AAA server.  This can happen in real
deployment in which there is an intermediate AAA domain between the
home AAA domain and visited AAA domain.

With regard to draft-housley-aaa-key-mgmt, there is a hint to indicate
to whom the keying material must remain confidential:

"
   For example, [RFC4072] enables EAP keying material to be delivered
   from a AAA server to a AAA client without disclosure to third
   parties.  Thus, key confidentiality is mandatory to implement in
   Diameter [RFC3588].  However, key confidentiality is not mandatory to
   use.
"

I have a doubt if hop-by-hop security is really acceptable for our key
distribution mechanism.

> 
> 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.

As Glen mentioned before, Kerberos-like architecture that supports
cross-realm operation can work without the keying material exposed to
a AAA proxy in the intermediate AAA domain.  Do you think that
Kerberos is not practical?

Also, depending on security policy, we may not fully trust the AAA
infrastructure.  Otherwise, why does RFC 3588 have the following text?

"
   It is strongly RECOMMENDED that all Diameter implementations support
   end-to-end security.
"

Regards,
Yoshihiro Ohba


> 
> --
> t. charles clancy, ph.d.  <>  [e-mail]  <>  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.  <>  [e-mail]  <>  eng.umd.edu/~tcc
> >>adjunct professor, electrical engineering, university of maryland
> >>
> >>_______________________________________________
> >>HOKEY mailing list
> >>[e-mail]
> >>https://www1.ietf.org/mailman/listinfo/hokey
> >>
> >
> 

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