Subject: Re: Making the hard choices on AAA security

From: Alain Zahm <[email-masked]>
Date: Tue, 16 Jan 2001 12:22:11 +0100

Hello,

I haven't been active since now on that list. Being involved in AAA
activity within my company, and following that thread I have a deeper
question on security issues then:

do we need to foresee the handling of delivery denial in DIAMETER? In
other words: do we need to ask a server signing the result of a request?
I understand that might be considered heavy but could become important in
wholesales area.

If the answer is yes then I think we'll have to think specifying security
at DIAMETER level.

At 23:19 03/01/01 -0800, you wrote:

The question of the day is:

"How simple can we make this and still solve

the problem?"

> One solution to this problem is the use of

> GSSAPI for end-to-end security for diameter.

> I have been investigating this since the San

> Deigo meeting. The use of GSSAPI would mean

> that implementations need not bind the AAA

> security to a particular mechanism.

A few questions:

a. How would GSSAPI work if you need more than

a single round trip? I assume we would carry

the GSSAPI tokens in the AAA request/response

messages, no? Is the restriction to a single

round-trip important or not?

b. What is the mandatory to implement GSSAPI

method for DIAMETER? KerbV?

c. Assuming we do this, are we done? In other

words, can we assume we *always* have at least

e2e authentication/integrity protection turned

on, and therefore don't need any hop-by-hop

security? Or do we need password hiding because

we may not always have confidentiality or

hop-by-hop auth/integrity because we don't

cover enough of the message with e2e?

How simple can we make this and still solve

the problem?

-----Original Message-----

From: Bernard Aboba
[mailto:[email-masked]]

Sent: Wednesday, January 03, 2001 8:22 PM

To: Aaa-Wg@Merit. Edu

Subject: Making the hard choices on AAA security

In the spirit of the AAA WG, which has always chosen

to tackle the hard problems early, I would like to

pose the following question:

"What is the minimum security functionality that we

need to meet the requirements?"

Notice, I didn't ask:

"How much security functionality can we cram in?"

In discussing security there may be an assumption

that we can have lots of security options.

For example, we might make shared secret

mandatory, throw in various options on hop-by-hop

(IPSEC, SSL), and for good measure specify a

couple of ways to do e2e security (CMS, Kerberos).

Therein lies the road to h*ll.

As Jeff Case has so eloquently stated, optional

features are bad. You have to implement them

because someone else might want to use them,

but you can never be guaranteed to reap the benefits.

I'd rather have one strong mandatory mechanism than

one weak mandatory one and an optional strong

mechanism.

So, the question is "what must we have?"

I think the case has been made that e2e security

is needed in *some* circumstances. Not all

circumstances -- for example, if you use

referal you don't need it.

Can we live with *one* e2e mechanism being

the *only* security mechanism we support?

If so, which one? If not, why won't this be

adequate?

And if we do this, can we get rid of the

RADIUS password-hiding mechanism?

If you think that we need hop by hop security

too, how many of *those* mechanisms do we need?

Can we live with *one* of those? Which one?

If you think that IPSEC alone will magically

sole our hop by hop security problems, think

about this:

a. IPSEC transport mode is not very widely

deployed today. In fact, I know of no RADIUS

deployment running over IPSEC.

b. Specifying IPSEC doesn't guarantee

instant interoperability. It's taken quite a

while to get interoperability between

L2TP/IPSEC implementations.

To summarize:

"There is no silver bullet, only hard choices".

Alain Zahm

SEMA GROUP TELECOMS

R&D Technical Director

Route des Lucioles - Les Algorithmes - Pythagore A

BP 279 - 06905 Sophia Antipolis Cedex

Phone: +33 (0)4 93 95 40 66

Mobile: +33 (0)6 89 87 12 49

Mailto: [email-masked]

PGP Key Fingerprint: F468 A906 F511 BFF7 CC8E 5F7C 5B42 2C06 B0C0
EF6B

Web:
www.semagroup.com

www.semagroup.com/telecoms

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 16 Jan 2001 09:01:17 -0800

A proxy can change an Access-Accept into an Access-Reject under the guise of
"policy". However, an Access-Reject should never be changed to an
Access-Accept. A good question is how this could be enforced, using any of
the solutions that have been proposed.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 16 Jan 2001 17:13:08 +0000

> Bernard Aboba wrote:
> 
> A proxy can change an Access-Accept into an Access-Reject under the guise of "policy". However, an
> Access-Reject should never be changed to an Access-Accept. A good question is how this could be
> enforced, using any of the solutions that have been proposed.

Not sure it could, but if the original Access-Accept is not encrypted
(if it is, I'm off home), I'd guess you'd have to invent a new AVP
"Access-Accept-Override" or somesuch.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Kaushik Narayan <[email-masked]>
Date: Wed, 17 Jan 2001 13:12:14 +0530 (IST)

bernard,

   hi! There are two issues here

  1> End-to-End Integrity Protection of the header - Actually
     the Kerberized Radius draft integrity protects some Radius header 
     attributes (like Radius code) on an end-to-end basis which means
     that a fraudelent proxy cannot modify the Radius code. Moreover
     since the end-to-end MIC is compulsory there protection against 
     deletion of the MIC itself. The end-to-end MIC would be generated
     using the end-to-end Kerberos session keys. The same behaviour 
     would be present in Kerberized diameter proposal.

  2> Protection against generation of an ACCESS-ACCEPT by a fraudelent
     proxy - A fraudelent proxy can actually generate an unsolicited  
     access-accept. The Kerberos draft would provide protection against
     this since the diameter authentication exchange would carry the 
     Kerberos key exchange messages (KRB_AP_REQ/KRB_AP_REP) and Kerberos 
     would perform a mutual service authentication based on messages. 
     Since the service principal is per server, only the homeserver would 
     be able to generate a valid KRB_AP_REP message, this would mean any 
     unsolicited ACCESS-ACCEPT/ ACCESS-REJECT generated by an fraudelent
     proxy would contain an invalid KRB_AP_REP messages and the Kerberos 
     mutual authentication would fail automatically.

   kaushik!

> 
> This is a multi-part message in MIME format.
> 
> ------=_NextPart_000_001E_01C07F9A.E31E0360
> Content-Type: text/plain;
> 	charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> 
> ------=_NextPart_000_001E_01C07F9A.E31E0360
> Content-Type: text/html;
> 	charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META http-equiv=3DContent-Type content=3D"text/html; =
> charset=3Dus-ascii">
> <META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR></HEAD>
> <BODY>
> <DIV><SPAN class=3D463285516-16012001><FONT face=3DArial color=3D#0000ff =
> size=3D2>A=20
> proxy can change an Access-Accept into an Access-Reject under the guise =
> of=20
> "policy". However, an Access-Reject should never be changed to an =
> Access-Accept.=20
> A good question is how this could be enforced, using any of the =
> solutions that=20
> have been proposed. </FONT></SPAN></DIV></BODY></HTML>
> 
> ------=_NextPart_000_001E_01C07F9A.E31E0360--
> 
> 
>

---

From: Steven Glass - Solaris Software <[email-masked]>
Date: Wed, 17 Jan 2001 17:15:47 -0500 (EST)

> Not sure it could...

    Maybe not from the solutions proposed, but the most straight-forward way
to do this (IMHO) is the way it's done in mobile ip.  We have a hash for
verifying the registration message wasn't altered in flight (among others). 
If the home agent says registration is OK, the mobile node needs to verify the
hash.  The foreign agent (analogous to the proxy in our model) could deny the
registration after seeing the home agent's OK, changing the reply code, but in
this way it can't say a denied registration is actually approved since it
can't generate the correct hash.  Yes, this means there has to be some sort of
secret already setup between the "approver" and "receiver"...

                              Cheers,
                                  Steve

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 18 Jan 2001 10:16:21 +0000

Steven Glass - Solaris Software wrote:
>     Maybe not from the solutions proposed...

Just for clarity, CMS, Kerberos and any other self-respecting 
e2e security solution will offer e2e data integrity. The "not 
sure" etc. refers to allowing one type of change and 
preventing/detecting another, not to simple integrity.

Stephen.