Subject: RE: [Dime] Supplicant X.509 AVP?

From: "Morrow, Glenn" <[email-masked]>
Date: Mon, 22 Jan 2007 14:40:42 -0600

We also want to avoid the overhead of having the applications send the
public certificate for the supplicant in the application signaling. 

-----Original Message-----
From: Morrow, Glenn 
Sent: Monday, January 22, 2007 8:36 AM
To: 'Hannes Tschofenig'
Cc: [email-masked]
Subject: RE: [Dime] Supplicant X.509 AVP?

Hi Hannes,

The decription on Scenario 3 is similar to what we are looking for i.e.
we want to apply assymetric cryptography enabled via certs directly to
the real signaling application (whatever it is) that Diameter is AAAing
without the extra signaling latency overhead of an EAP-TLS server or
another SA setup with a cert directory from the Diameter client or
end-application itself.

As a simple example, if we had a UDP application that had a client
component and a network server component, We want the UDP application
client to sign their packet with their private key and send the message
to the network server component. 

We then want the Diameter client (co-resident with the network server
component) to retrieve the public key from a Diameter server which then
retrieves it from a cert directory or whatever PKI backend solution
there is and relay it down to the Diameter client along with any
additional application specific authorization information for the
end-user application.
 
The Diameter client then passes this information to the network server
component of the application which then uses the public key in the
public cert to check the integrity of the UDP application packet and
authenticate the supplicant (end-user/device/whatever). Once
authenticated the authorization policies of both the public cert and any
Diameter application policies are allowed/enforced. 

We are quite happy with existing Diameter to Diameter server/client
security and transport i.e. scenario 1.

Again - we want to avoid the extra signaling latency overhead of an
EAP-TLS server or another SA setup with a cert directory from the
Diameter client or end-application itself. Passing the public cert down
is far more efficient and greatly improves the application setup delay.

Please let me know if this clarifies the terminology and what we are
looking for.

Thanks,

Glenn

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: "Morrow, Glenn" <[email-masked]>
Date: Tue, 30 Jan 2007 18:54:46 -0600

We also don't want to have to have to transport the cert at all at the
application level - just start signing and digesting from the get go -
granted challenge/nonce etc.. needed later as well.

-----Original Message-----
From: Morrow, Glenn 
Sent: Tuesday, January 30, 2007 5:49 PM
To: 'Glen Zorn (gwz)'; Madjid Nakhjiri
Cc: [email-masked]; Hannes Tschofenig
Subject: RE: [Dime] Supplicant X.509 AVP?

Yes there are other protocols that pass certs and these would likely be
used as the backend for the Diameter Server. I.e. the Diameter Server is
the application to these existing protocols. We just don't want to have
to do two dips and that is why we want to transport the cert with
Diameter - get it all done with one transaction from the Diameter
client/Application Server perspective - not two. 

> 
> Seems like a Diameter based cert status checking mechanism..

Hmm -- that's not what I'm getting at all, but if you're right it seems
like there are already at least a couple of other standard protocols
that do this...

...