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

[Yoshihiro Ohba <[e-mail]>]

Glen,

A consensus in a face-to-face meeting does not mean it's final
consensus simply because not all WG members can participate in
face-to-face meetings.  It needs to be confirmed over the WG mailing
list.  Otherwise, what is the purpose of this consensus call?

I would like to hear more technical opinion from other WG members on
this fundamental issue rather than seeing further discussion being
shut up administratively.

I believe that RFC 4902 is generic enough to cover proxy environment.

Regards,
Yoshihiro Ohba


On Thu, Aug 09, 2007 at 10:25:18AM -0700, Glen Zorn (gwz) wrote:
>  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.
> "
> 
> One of the major problems with that draft (now RFC 4962) is that while claiming to be "guidance for AAA key management", it essentially ignores the question of proxies.
> 
> I have a doubt if hop-by-hop security is really acceptable for our key
> distribution mechanism.
> There was clear consensus at the Chicago meeting to utilize the "standard AAA methods" for key transport.
> 
> 
> >
> > 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?
> There was clear consensus at the Chicago meeting not to use Kerberos.  Given that that consensus has not been contradicted on the list, I think that this conversation is over.
> 
> Also, depending on security policy, we may not fully trust the AAA
> infrastructure.  Otherwise, why does RFC 3588 have the following text?
> Because the editor forgot to take it out?
> 
> "
>    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
> 

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