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

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 01 Feb 2007 16:42:58 -0800

If you don't want to do EAP-TLS because of the roundtrips involved in
EAP-TLS and just want to use Diameter to check a cert, then it is a cert
status checking signaling through Diameter.
If you understand your scenario, you want to authenticate an ID that an end
user application client is using for that application by using a private key
and send a cert along to prove it. The application  server cannot check the
cert, so it resorts to the Diameter infrastructure to hit the CA or Cert
status checking server.

Isn't this your scenario?

Madjid

-----Original Message-----
From: Morrow, Glenn [mailto:[email-masked]] 
Sent: Tuesday, January 30, 2007 4: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...

...

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: Madjid Nakhjiri <[email-masked]>
Date: Thu, 01 Feb 2007 16:48:02 -0800

One more question. Is your certificate profile application-specific? Or the
user uses one cert for any type of application?

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

...

---

From: "Morrow, Glenn" <[email-masked]>
Date: Fri, 2 Feb 2007 09:03:52 -0600

Good points Madjid:

1) If you don't want to do EAP-TLS because of the roundtrips involved in
EAP-TLS and just want to use Diameter to check a cert, then it is a cert
status checking signaling through Diameter. If you understand your
scenario, you want to authenticate an ID that an end user application
client is using for that application by using a private key and send a
cert along to prove it. The application  server cannot check the cert,
so it resorts to the Diameter infrastructure to hit the CA or Cert
status checking server. Isn't this your scenario?

GM> 
I would like to simply define an AVP to transfer a certificate chain
that could be for many scenarios and applications:

a) Use of Diameter as an AAA protocol between a local TLS or EAP-TLS
server and a home network to do the certificate verification. In these
scenarios the certificate would be passed via TLS or EAP and the
application clients certificate would be passed over Diameter to the
application server in the network.

b) Use of Diameter as an AAA protocol to applications that use the
asymetric keys of the certificates to hash/sign/digest the application
signaling directly e.g. on the applications' registration or setup
flows. Symmetric keying material can be created during this exchange for
subsequent transactions. In these scenarios none of the certificates
would pass over the application signaling but the certificate is passed
over Diameter to the application server in the network so it can perform
the crytographic operations using the public key contained in the
certificate.
/GM>

2) It is understandable to not want to touch the app. However, it seems
that the authentication and application authorization (using the cert)
needs to happen before the application starts, so how do you want to
handle the AAA exchange, something must trigger the exchange and that
something has to come from the application itself.
GM> 
The application must certainly start the process (in the case of a) or
be the process itself (in the case of b).
/GM>

3) One more question. Is your certificate profile application-specific?
Or the user uses one cert for any type of application?

GM> Certficate profiles should actually be deployment specific. I would
prefer to the leave cert profiles to each application and even each
deployment of application as needed. The ID I'm looking for here is
simply an AVP definition to pass a certificate over Diameter. If
diameter is used as the AAA protocol for an application then that
application and even deployment of that application must document the
cert profiles as well as other fields as AVPs that may or may not be
contained solely within the certificate profile. The cert AVP ID should
contain such suggestions for use probably in the security section.

Thanks,
Glenn
GM>

---

From: "Morrow, Glenn" <[email-masked]>
Date: Fri, 2 Feb 2007 09:42:50 -0600

Maybe we should just name the AVP to be "client_application_credentials"
and include a subtype string to identify the type of credential and then
another type for the material itself. This would be generic enough to
handle not only certs but all sorts of other keys as well?

-----Original Message-----
From: Morrow, Glenn [mailto:[email-masked]] 
Sent: Friday, February 02, 2007 8:04 AM
To: Madjid Nakhjiri; Glen Zorn (gwz)
Cc: [email-masked]
Subject: RE: [Dime] Supplicant X.509 AVP?

Good points Madjid:

GM> 

certificate. /GM>

be the process itself (in the case of b). /GM>

Thanks,
Glenn
GM>

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.