[AAA-WG]: IETF 60 meeting minutes

[<[e-mail]>]

AAA WG meeting Tuesday, August 03, 2004, IETF-60, San Diego
Minute taker:
Lakshminath Dondeti, [e-mail]
+++++++++++

NASREQ: some comments off the mike

Diameter: waiting for Allison M., comment

Diameter EAP finished WG last call

DIAMETER-SIP and aaa-uri in AAA WG last call

First session presentations:


Diameter EAP: Pasi E.

first WGLC ended in Seoul meeting

Clarifications
Which application id to be used.

Open:  issues 465-7 

Proposal to incorporate 465 and 466 , but not 467

Send to IESG

%no discussion
 
+++++++++++++++++
EAP key management issues:  Bernard, A.

Review of the doc:  

participants: EAP peer (multiple ports), Authenticator w/
multiple ports, and then the AS

0 Discovery
1 Authentication
1a EAP auth
1b AAA key xport
2  SA establishment
2a unicast
2b multicast

Conversation: 

Requirements: Outlined by Russ H at IETF-56

Algorithm independence, fresh and strong keys, replay detection,
authenticate all parties.

+ perform client and NAS authorization
+ Maintain confidentiality of sess keys
+ confirm selection of best suite
+ address cascading vulnerability problem
+ bind key to ctxt

*Some relate to AAA*

EAP: media, method and ciphersuite independence

Types of EAP keys: calculated locally, exported by EAP method, etc.,

EAP key hierarchy: changes: long term credential

Key naming: MSK, EMSK, AMSK, AAA-Key

Key lifetime issues: negotiation, out of band mgmt

Lifetime mgmt:
Transient EAP keys

existing attr: session-timeout
AAA-Key caching

Glenn Z., force key lifetime to be of the same lifetime as the session
can't have a key lifetime shorter than session lifetime

Bernard: can conceivably do rekeying during a session
do you rekey or reauth to renew?

G Z: force rekey and reauth to be the same

Pasi E: since EMSK is between client and AAA server; they talk EAP, which
does not separate reauth and rekey.

B A: in WPA can rekey without reauth

Jari A: that's a rekey at a lower layer

B A: need to be clear about what is being rekeyed

Pat C: PMK rekey vs. PTK rekey 

B A: w.r.t exported keys there is no rekey without reauth (Transient
keys can be rekeyed)

G Z: in EAP that's true; from AAA pov it's not true.
e.g., session timeout is forever; but we want to change key without
reauth

B A: this is not the same as fast resume

J A: problem with AAA rekeying GZ proposes is that we need a new
mechanism

P E: EAP can't do that!

J A: it's DIAMETER EAP; probably something that can be done in the
future; not in any of the current WG docs

??: not good to cache EMSK

J A: can you explain that? If you don't cache the EMSK, when can the app
request an AMSK

??: app based

J A: how would that work: chick and egg problem

??: discuss in 

B A: EAP WG

more on this at the EAP WG ...

++++++++++++++++++++++++++++++++++

Glenn Z:  Alternative EAP keying approaches.
1. RADIUS-keywrap

Govt requirements

This makes it easy for companies to sell to govt bodies:

Just use IPsec does not work: run RADIUS over IPsec; hardly anyone supports it

does not authenticate to a process which you are speaking

vulnerable to Trojans (talking to right box, without the right
server/process does not work)

Is not possible for an app to know that IPsec is running; need
verifiable security.

App layer security is better.

Pasi E:  widely known that IPsec for app layer security does not work.

G Z: IPsec might require a PKI for "proper" operation

J A: keywrap is better.  Works for DIA/RAD.  key protected by TLS can be
"keywrap"ped.

P C: NIST approval is still harder.  MD5 is still used

G Z: no there is no MD5

2. RADIUS-keyreq

EAP rekeying and authentication are the same operation.

AAA client authenticating to server or vice versa, and needs a new key
is the app being considered.

J A: Q: Is this not going to be applied for RAD/DIA?

G Z: can't think of why not?

J A: we are not doing another keying model!

??: 

Missed some discussion between Bernard and Glen

John L: does not impact RAD/DIA.  So, no updates needed there.

++++++++++++++++++++
2nd session
++++++++++++++++++++


Diameter Mobile IPv4:

18 & 19  Addressing IESG comments

++++++++++++++

NASREQ-17:

fixing last minute issues/bugs, and addressing IESG review
doc going to the RFC editor

Changes:

issues: 464, 466, 468
++++++++++++++

CC-05:

Addressing Allison M.'s discuss:

I: Too 3GPP specific 
A: AVPs are extensible

I: need to think broadly about SIP
A: will add text

I: Message flow diags too 3GPP specific
A: will update to be more general

IANA issues TB addressed

Ted H Discuss:

I 4.1 needs clean up:  guidelines for interoperability
A: proposed text ok'ed

I: 5.5

I: credit fragmentation

(has been cleared)

> Allison's Discuss needs to be resolved

G Z: add service id AVP

Glenn Z: don't understand how this is expected to work thru anything
other than a case where there is a direct connection with a BCC server.
Dropping that issue, but that was the issue.


++++++++++++

AAA-URI:

Updating 3588

-01- in WGLC, ending Aug 18th; please send comments

latest changes are editorial; no known open issues

++++++++++++
Diameter-SIP-03

in WGLC, ending Aug 26th

need comments
need to analyze comaptibility with draft-sterman-aaa-sip

B A: last opportunity to review; this will be deployed widely, so please
review.

will request SIP & SIPPING WG for review

changes: SIP registration -> SIP soft state management
            -> digest-expected-response AVP
       updatd: authentication details section

Please use the issue tracker:

http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/

e.g., open issue 14: support for qop=auth-int
SIP UA <--> SIP server <---> Diameter server

SIP server creates the hash upon indication from DIAMETER server.


++++++++++++

DIAMETER QoS application

why? 

% Authn Authz for QoS req, and Acc for QoS reservations
More discussion in NSIS

interface to app servers:
  allow them to dynamically authorize/de-authorize flows
  propogate knowledge of bearer flows
  ...

Without this:
  every QoS routing domain deploys an app server
  
with this:

subscriber DB <-> diameter cloud <-> app server
                        ^
                        |
                        v
                  Bearer entity
advantages:

uniform interface etc

lot of open issues ...

need to carry authentication for NSIS

??: don't understand your QoS diagrams/model

A: please send comments to AAA list of NSIS list

J. L: as NSIS WG co-chair: 

need something like this in NSIS; not sure this fits exactly

B A: after negotiation, what if a "big fish" kicks you off

J. L: hum

interested: several folks
not interested: none (inaudible)

will talk to Allison M on how to progress

individual I-D, sponsored by her; will run WGLC process in AAA WG.

this was agreed upon by other chairs and the author.

++++++++++++++++++++++++++
This will/could be the last meeting of the AAA WG.  The mailing list
will continue to exist.  There may be a subsequent DIAMETER maintenance
WG.