Subject: [Dime] Supplicant X.509 AVP?

From: "Morrow, Glenn" <[email-masked]>
Date: Fri, 19 Jan 2007 09:25:37 -0600

Greetings to all,

We'd like to begin exploring the use of certificates as credentials for
several AAA applications and would prefer to use the keying material for
integrity and authentication at the application signaling level itself.
The flows for this type of deployment and thus application latency of
application setup are greatly reduced (no need for yet another SA setup
and message exchange to yet another network entity such as a secure
directory/repository for public certs, No EAP-TLS overhead)  if the
certificates are transpoted over Diameter from the server to the client.

I'd like to float this concept to the WG and see if others have existing
or planned implementations and would like to colloborate on an ID to
define a supplicant certificate AVP to be a base Diameter AVP such that
it could be used for any Diameter application. I have not floated this
to the Radius extension WG due to the UDP transport. I think that if
Radius is used, the EAP-TLS or a separate directory lookup from the
client is the only option available. There should be no such limitation
on Diameter though.

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: Hannes Tschofenig <[email-masked]>
Date: Sun, 21 Jan 2007 15:38:35 +0100

Hi Glenn,

Thanks for raising security questions. Let me describe three different 
usage scenarios and you tell me which one you have in mind:

1) Security protection between neighboring Diameter entities

2) Security protection between the Diameter client and the Diameter server

3) Establishment of security associations between an end host and the 
Diameter client

Ad 1) The classical solution is to use TLS or IPsec.
See the Security Considerations section in 
http://www.ietf.org/rfc/rfc3588.txt

Ad 2) A solution was once proposed that uses certificates as part of CMS.
This work was done as part of the AAA working group but stopped due to 
lack of interest. Here is the latest document:
http://tools.ietf.org/wg/aaa/draft-ietf-aaa-diameter-cms-sec/draft-ietf-aaa-diameter-cms-sec-04.txt

The main benefit of CMS is to digitally sign or encrypt AVPs in an 
end-to-end fashion between the Diameter client and the Diameter server.

Ad 3) This solution is an entirely different usage scenario and might, 
for example, be used for network access authentication where the 
user/end host is authenticated to the Diameter Server (or EAP server) 
via the Authenticator (Diameter client). If network access 
authentication was successful then the Diameter Server (or EAP server) 
transports keying material to the Diameter Client and uses it in a 
subsequent protocol exchange between the end host and the Diameter client.

For network access a number of documents are available and you might 
want to look at:

* Diameter Network Access Server Application
  http://www.ietf.org/rfc/rfc4005.txt

* Diameter Extensible Authentication Protocol (EAP) Application
  http://www.ietf.org/rfc/rfc4072.txt

* Extensible Authentication Protocol (EAP) Key Management Framework:
  http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-16.txt

* EAP (see http://www.ietf.org/rfc/rfc3748.txt) and various EAP methods
 
Ciao
Hannes

 > -----Ursprüngliche Nachricht-----
 > Von: Morrow, Glenn [mailto:[email-masked]]
 > Gesendet: Freitag, 19. Januar 2007 16:26
 > An: [email-masked]
 > Betreff: [Dime] Supplicant X.509 AVP?
 >
 > Greetings to all,
 >

---

From: "Morrow, Glenn" <[email-masked]>
Date: Mon, 22 Jan 2007 09:36:05 -0600

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

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 29 Jan 2007 16:49:49 -0800

Hi Glenn, Hannes,

In an old BoF, we presented a similar problem as "application keying", there
we assumed that we already had done EAP method (e.g. EAP-TLS) but we wanted
to use the keying material resulting from EAP to generate keying material
for the application at hand. It seems that Glenn wants to avoid the EAP
latency all together, but use Diameter as a method to help out with public
key fetch. If the PKI is present to provide client certs, why not.

I think exploring support for certs handling and application keying is
interesting and I am interested in scenario described.

R,

Madjid

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

Hi Hannes,

 

Thanks,

Glenn

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Mon, 29 Jan 2007 19:44:48 -0800

Madjid Nakhjiri <mailto:[email-masked]> allegedly scribbled on
Monday, January 29, 2007 4:50 PM:

> Hi Glenn, Hannes,
> 
> In an old BoF, we presented a similar problem as "application
> keying", there we assumed that we already had done EAP method (e.g.
> EAP-TLS) but we wanted to use the keying material resulting from EAP
> to generate keying material for the application at hand. It seems
> that Glenn wants to avoid the EAP latency all together, but use
> Diameter as a method to help out with public key fetch. If the PKI is
> present to provide client certs

What is meant by "client" here?

> , why not.  

Depends to a large extent upon the answer to my question above, IMHO.
More comments below.
    
> 
> I think exploring support for certs handling and application keying
> is interesting and I am interested in scenario described. 
> 
> R,
> 
> Madjid
> 

How do you authenticate a supplicant using the cert for an app client?

> security and transport i.e. scenario 1.

That's too bad, since the existing Diameter security is little better
than that of RADIUS (in the best case).

---

From: "Morrow, Glenn" <[email-masked]>
Date: Tue, 30 Jan 2007 10:32:32 -0600

Inline GM>

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

Madjid Nakhjiri <mailto:[email-masked]> allegedly scribbled on
Monday, January 29, 2007 4:50 PM:

> Hi Glenn, Hannes,
> 
> In an old BoF, we presented a similar problem as "application keying",

> there we assumed that we already had done EAP method (e.g.
> to generate keying material for the application at hand. It seems that

> Glenn wants to avoid the EAP latency all together, but use Diameter as

> a method to help out with public key fetch. If the PKI is present to 
> provide client certs

GM> Madjid knows for sure but I believe he meant the end-application
client. I.e. not the diameter client.

    

> 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
> client to sign their packet with their private key and send the 
> message to the network server component.
> 
> 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.
> 

> authenticated the authorization policies of both the public cert and 
> any Diameter application policies are allowed/enforced.

GM> Digital Signatures, encrypted confidential fields, Message Hashes
with Salt and Nonce material using the public and private keys instead
of symmetric keys. The public cert chains (for the application servers)
are either predistributed or retrieved once from a secured directory and
cached in a ring as needed. 

GM> Please discuss more or do an ID or point to a URL/Wiki with a list
of what needs to change?

> Diameter client or end-application itself. Passing the public cert 
> down is far more efficient and greatly improves the application setup
> delay. 
> 
> This communication is the property of Qwest and may contain 
> confidential or privileged information. Unauthorized use of this 
> communication is strictly

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 30 Jan 2007 10:49:54 -0800

Glen, 

I picked the term "client" off Glenn's description:  

" As a simple example, if we had a UDP application that had a client 
> component and a network server component,..."

Glenn assumes there is a application server and an application client.
The app client signs a message/request with a private key. 
He wants to use Diameter infrastructure to help the application server (a
network service equipment) to get a public key and verify the signature.
This is architecture I see:

Client------>Net server------Diameter------------>Diameter
app			app  	     Client 			server
				<------	      <------	^ |
									| V
								X.501
directory

Seems like a Diameter based cert status checking mechanism..

R,

Madjid

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

    
> i.e. 

> then 
> any 

> down 
> confidential or

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 30 Jan 2007 13:23:42 -0800

Morrow, Glenn <mailto:[email-masked]> allegedly scribbled on
Tuesday, January 30, 2007 8:33 AM:

...

>> Digital Signatures, encrypted confidential fields, Message Hashes

Supplicant != app client (at least in any architecture of which I'm
aware).  Diameter facilitates the authentication & authorization of
users, not random pieces of software.  BTW, I am aware of methods for
X.509-based authentication, thanks -- my question was WRT identities,
not methods.

>> Please discuss more or do an ID or point to a URL/Wiki with a list
>> of what needs to change? 

There are two methods stipulated for the cryptographic protection of
Diameter messages: IPsec & TLS.  Both are hop-by-hop only, just like
RADIUS (despite the nonsense about redirection in RFC 4072).
Furthermore, IPsec only authenticates IP addresses, not software
entities, making it actually less secure than the RADIUS method (which
at least can authenticate the RADIUS client to the RADIUS server instead
of the boxes upon which the software components happen to be running.

>> down is far more efficient and greatly improves the application
>> setup delay. 
>> 

Not really, or maybe I'm just dense.  What or whom, exactly is being
authenticated here?

...

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 30 Jan 2007 13:56:12 -0800

Madjid Nakhjiri <mailto:[email-masked]> allegedly scribbled on
Tuesday, January 30, 2007 10:50 AM:

> He wants to use Diameter infrastructure to help the application
> server (a network service equipment) to get a public key and verify
> the signature. This is architecture I see: 
> 
> 
| V
> 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...

...

---

From: "Morrow, Glenn" <[email-masked]>
Date: Tue, 30 Jan 2007 17:52:03 -0600

...

Quite true - perhaps we can work together on the baby steps necessary to
at least get rid of the alleged. Not sure what we can do about the
scribbles though :)

Supplicant != app client (at least in any architecture of which I'm
aware).
GM> I am thinking that "access" is one such "application" or "service"
if you will? If access is the application does supplicant=app client
then? If supplicant is the wrong term. What shall we use as the correct
term to represent the entity being AAA'd for all such services or
applications which can be AAA'd? I am certainly open to a new term. I am
happy with "application client" as the terminology as long as "access"
is an application whereby the certificate can be used. I don't care what
we call it just as long as we know what it is. Pick a term and let's
just use it.

Diameter facilitates the authentication & authorization of users, not
random pieces of software.
GM> Not sure how to respond to this other than to attempt to re-scribble
:) it to say," AAA protocols facilitate the AAAing of users to use
services and perhaps it might be odd that quite often these services are
actually implemented using seemingly  random pieces of software." :)

BTW, I am aware of methods for X.509-based authentication, thanks -- my
question was WRT identities, not methods.
GM> Sorry about my interpretation of the question. Did not mean to
insult you. You are definitely not someone I'd like to have on my bad
side :)

GM> As far as entities go. I see the advantage of using certs on the
applications or services if you will, themselves, to be that the
applications can include extra fields such as: user and device and
subscriber id, "random software or protected memory" :) checksum hashes,
account ids etc... instead of just relying on a transport or can'd
authentication-only security mechanism such as EAP or TLS or IPSEC. I
suppose it is this random software through OS protected memories,
password protected dongles or other external devices, etc.. with
physical and software protections in place to attempt to protect the
credentials contained in the certificates with the credentials being
used for the application. ACLs and security policy can be used to
enhance transport solutions in an infrastructure solution i.e. a bunch
of static servers deployed statically by a provider of some sort. Even
with ACLs and policy, the security is still limited for transport only
solutions and your points below about Diameter, itself, are exactly why
EAP and TLS/IPSEC don't fix the wagon by themselves. Simple transport
only ACLs and Policies fail completely when applied to a roaming user
which may be on a plethora of devices using different OSs and different
credential systems, etc.. - much less trying to do single sign on in a
federated service environment.

GM> Sorry the scribble ramble there. Answer is user/device and/or both
depends on the application and the application should define this.

>> Please discuss more or do an ID or point to a URL/Wiki with a list of

>> what needs to change?

GM > Agreed - I could discuss ACLs and policy in an infrastructure
environment but you are right in that there is room for considerable
improvement. E.g. we could add a digest to Diameter as well? I am not
apposed to this as long as the keying material for the digests are
derived from an initial transacation utilizing asymmetric keys and all
subsequent server to server communication can be encrypted. 

GM> Believe me  - you are not dense. The user, device or both
simultaneously depending on the nature of the service or application
being AAA'd.

...

---

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

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. 

...