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

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

My name is mentioned a few times in the below Minutes.
I was not on the call (as I had mentioned beforehand).
I did send in my input, and it might be usefull to include
that in your minutes, so that it is also clear that from
my ID-tracker comments, there are no blocking issues left. 

Thanks,
Bert 
--- here is what I wrote:
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: maandag 12 mei 2003 12:11
To: Bernard Aboba; iesg@ietf.org
Cc: aaa-editors@internaut.com
Subject: RE: Conference call on draft-ietf-aaa-diameter-mobileip-14.txt


My comments were only nits.
They have been addressed except for the fact that 
the reference to RFC2119 is still listed as informative,
while (as far as I know) the IESG believes it should
be listed as a normative reference.

Can be done by an RFC-Editor note or during 48-hour authors call.

So I won't dial in into the call.

Thanks,
Bert 

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com]
> Sent: woensdag 21 mei 2003 5:06
> To: iesg@ietf.org
> Cc: proberts@megisto.com; aaa-editors@internaut.com; gab@sun.com
> Subject: Minutes of the 5/19/03 MIPv4/AAA conference call
> 
> 
> 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.
>