Minutes of the 5/19/03 MIPv4/AAA conference call

[Bernard Aboba <aboba@internaut.com>]

Minutes of the 5/19/03 MIPv4/AAA conference call

Attendees: Bernard Aboba, Tony Johansson, David Mitton (AAA WG),
Jari Arkko (EAP WG), Phil Roberts, Gab Montenegro,
Basavaraj Patil (MOBILEIP WG), Thomas Narten, Erik Nordmark,
Randy Bush, Steve Bellovin (IESG)

Scribes: Basavaraj Patil, Gab Montenegro


BA: Do we have all the comments on the MIPv4/AAA draft?
Initially comments from Diameter Base were placed in
Draft tracker instead of from this draft.  Now the
draft tracker entry shows a discuss from Bert Wijnen,
Thomas Narten and Steve Bellovin, but only comments
from Steve and Bert, none from Thomas.

BA: Thomas, did you have comments that didn't end up in
draft tracker?

Thomas: Yes, I did. I will dig up the mail and send
the comments in.

Steve -- are your comments in draft tracker complete?

SMB: Yes.

BA: At IETF 56, Russ Housley gave a presentation on proper
keying handling for AAA applications.  Do those comments
apply to this draft as well?  Should they be included in
Draft Tracker:

Thomas: Yes, the comments apply, and they should be included.

BA: OK.  Let's move on to discussion of whether the -14 submitted
by Tony addresses Steve and Bert's comments.

SMB: I do not believe that my comments on Section 5 have been
addressed in -14.

"I confess that it still isn't clear to me how the home and foreign
agents know authoritatively who each other are. Then again, that's
always been my main complaint about AAA. But here they're handing out
keys."

SMB: It is very hard to prove in a qualified manner the identity of the
FA to the HA.

BA: In general, Russ's requirements are that each pair of parties in the
exchange mutually authenticate to each other and also protect each packet
sent in the exchange (authenticate, integrity protect, replay).  Can we
show that this is happening here?  If not, can we make it happen?

Note that authenticating via certificates is not enough.  That tells you
who the other party is -- but you have to check that they're authorized
for the role they're playing.  For example, my laptop at work has got an
IPsec certificate.  That doesn't qualify me to set up my machine as a VPN
server to connect the corporate network to the Internet. Similarly, even
if the FA and HA mutually authenticate, that doesn't mean that the FA and
HA are authorized to play those roles.  You've got to check this somehow.

SMB: My comments relating to security associations were also not addressed
in -14.

Tony: this is covered in the AAA-Keys and MIPv4 specifications.
Note that the AAA keys specification is till being revised and
terminology is being worked on.

Phil: Luis last year did a security review.
Thomas: Well, perhaps it's time to do this again.
Erik: aaa-keys hasn't gone to IESG yet.
Phil and Thomas: Not yet.

BA: One issue that Russ has raised is whether AAA keys are obtained by
intermediaries such as proxies.

Tony: In most cases, the "keys" are really just nonces, not true
keying material.

BA: I went through the draft and submitted corrections for that usage.
So I think that is fixed. We are only talking about keying material
here, not Nonces.

If there are true keys being transmitted through proxies, then we have
got a problem.  Since AAA WG is not moving forward with CMS (no interest),
the best we can do is to make sure that keys bypass proxies by using
Diameter redirect, so that keys go end to end.  The keys can be protected
by TLS, based on configuration of appropriate trust anchors on the
Diameter agents.  This is what we are proposing for Diameter EAP.

If there is a need for proxies to see authorizations other than keys, then
we will need to allocate a separate application ID for the key messages
(and possibly a separate command), so that those messages can be routed
separately via redirects. The proxy can modify the other authorizations,
but not the keys since it won't see them.

But again, this is only required if keys would otherwise be handled by
proxies.

SMB: Another issue is how Diameter agents authorize each other. That
comment was not addressed.

BA: This is a generic issue with AAA. We had to deal with this in RFC
2869bis and Diameter NASREQ.  Both drafts have added similar text.

Basically, the problem is that a NAS can attempt to impersonate another
NAS. If the downstream agents don't check that the NAS Identification AVPs
match the source address, they may not detect the impersonation.   They
will just verify the TLS certificate, but not notice that the identity in
the cert does not map to the identity in the Diameter message itself, or
to the source IP address.

Once a NAS can impersonate another one, it can cause keys to be generated
and sent to other NASes, create false accounting records, etc.  This is
not good.

Some simple checks can fix this. Each Diameter agent must check NAS
identification AVPs against the source address.  If they don't match, the
packet is discarded. There is also the Record-Route AVP where entries are
added by the downstream agent, *not* the NAS. This works like Kerberos
realm traversal.

Next Steps:
===========

1. Comments from Thomas Narten and Russ Housley to go into draft tracker.
2. Tony to add the text based on RFC2869bis and Diameter Nasreq
   app. into the Diameter-MIPv4 app to deal with impersonation, and
   authorization.
3. If there are any true keys being sent (not Nonces) via proxies, we need
   to make those AVPs go end-to-end via redirects. No need to reference
   CMS, since AAA WG will not be going ahead with CMS.
4. Tony to add clear diagrams showing what messages are passing between
   what entities and where keys and nonces go.  This is essential if the
   IESG is to understand the relationship between the entities and what
   quantities are possessed by each party and passed back and forth
   between them.
5. Try to get this all wrapped up in a months time.
6. Tony to discuss with Tom to get the AAA Keys draft completed.
7. Bernard to setup a teleconf next month (June) to ensure all AD
   comments have been addressed in revised documents. By then we are
   expecting a -15 draft addressing IESG comments.