[03:59:02] --- davidbnelson has joined
[04:08:57] --- adekok has joined
[04:09:12] <adekok> We now have a jabber scribe.
[04:09:29] <adekok> (Some attempts to get the projector to work)
[04:09:42] <adekok> Bernard: All presentations are online. Blue sheets circulating.
[04:09:59] --- afh@jabber.netzwert.ag has joined
[04:10:01] <adekok> Bernard: outline agenda && document status. Agenda posted.
[04:10:07] <davidbnelson> Ah, that's what all the "clunking" was on the streaming audio...
[04:10:14] <adekok> Call for additions/deletions... none
[04:10:27] <adekok> 2 documents in RFC editor Q, prefix && filter rule
[04:10:42] <adekok> 3 in last call, 4590bis, 3576bis, Issues & Fixes
[04:11:30] <adekok> call for review on lior-extended attributes.
[04:11:35] <adekok> (Glen says he loves it)
[04:11:49] <adekok> (One other person has read it)
[04:12:08] <adekok> Bernard asks attendees to read it while in the room.
[04:12:26] <adekok> indivisual disvussions with outstanding review comments... all on WG issues list.
[04:13:13] <adekok> Now going to 4590bis
[04:13:22] <adekok> Wolfgang Beck
[04:13:46] <adekok> document is errata for 4590. Some comments on list.
[04:13:55] <adekok> New features, like adding attributes to accounting packets.
[04:14:12] <adekok> Not sure if this is OK... are we fixing the document or adding features?
[04:14:19] <adekok> (Bernard: nothing quick in the IETF)
[04:14:39] <adekok> Issues 196 addressed
[04:14:48] <adekok> Issue 205: IANA error
[04:15:17] <adekok> Issue 206: Digest-Method optional, State attribute usage not clear
[04:15:25] <adekok> Add clarifying text
[04:15:30] <adekok> Make Digest-Method mandatory
[04:15:58] <adekok> Bernard: correlate State to Nonce is special for Digest
[04:16:05] <adekok> Issue 218: Accounting-Request entries.
[04:16:19] <adekok> Bernard: does this mean you couldn't put these attributes in an accounting request?
[04:16:32] <adekok> Bernard:trying to come with list that could go into a packet
[04:16:47] <adekok> Bernard: trying to figure out where existing attributes can be put, when the are legal, people need to know
[04:16:59] <davidbnelson> Bernard needs to be closer to the mic
[04:17:40] <adekok> Bernard: any other attributes not listed in table in Issue 218 that are useful in accounting-Request?
[04:18:03] <adekok> Done.
[04:18:41] <adekok> Wolfang: Most make sense...
[04:19:00] <adekok> Bernard: it would be good if people looked at this on the list: last remaining thing before submission to RFC editor
[04:19:19] <adekok> Bernard: everyone look over this, so we don't go through this again.
[04:19:29] <adekok> Bernard: put out -01, have a week for reviews, hopefully have it done.
[04:19:48] <adekok> RFC 3576bis
[04:20:38] <adekok> Bernard Aboba:
[04:20:45] <adekok> Issues came up in review, Issue 212
[04:21:04] <adekok> Should we change the terminology to be compatible with the MIBs?
[04:21:25] <adekok> Inclination to not change it, because it's a lot of work. Call for opinions.. ? No.
[04:21:32] <adekok> Issues with replay protection.
[04:21:42] <adekok> Event-Timestamp looks like it's difficult to use.
[04:21:53] <adekok> Duplicate detection can't be done with Event-Timestamp (requires new Id's)
[04:22:06] <adekok> Backwards compatibility for Nonce... What's going to happen?
[04:22:28] <adekok> Suggestion is to say only send this Nonce if the other guy can deal with it, otherwise he NAKs it.
[04:22:38] <adekok> 32-bits isn't big enough. 128 or larger
[04:22:45] <davidbnelson> Sounds like a need for capability advertisement?
[04:22:54] <adekok> RPF check (reverse proxy check)
[04:23:31] <adekok> (capability) Bernard says not as part of this
[04:23:37] --- kasumigaura has joined
[04:24:12] <adekok> Bernard: prob lem with check is NAK with error message saying "unsupported attribute", but it doesn't say what.
[04:24:20] <adekok> RADIUS-Diameter error message translations.
[04:24:39] <adekok> Bernard put in mapping... maybe it's right? Is anyone willing to check?
[04:24:44] <adekok> Issues 215
[04:25:01] <adekok> Why Authorize-Only in Disconnect-Request.. . may be ludicrous.
[04:25:13] <adekok> Diameter compatibility claims are wrong. There's no need for it.
[04:25:27] <adekok> Has anyone implemented it? If not, can we just take it out?
[04:25:38] <adekok> Or turn it from optional to MUST NOT
[04:25:48] <adekok> Nobody on list speaks up for it... get rid of it.
[04:25:55] <adekok> Issue 223: Event-Timestamp
[04:26:04] <adekok> Somewhat lame replay
[04:26:29] <adekok> RFC 2869 Section 3 prohibits Event-Timestamp except in Accounting-Request.
[04:26:38] <adekok> Inclusion will invalidate duplicate detection.
[04:27:29] <davidbnelson> I think it was supposed to be thetime of the event, not the transmission.
[04:27:38] <adekok> Question: Is the Event-Timestamp the time of the original event that caused the packet to be sent?
[04:27:51] <adekok> So... it doesn't change on retransmit, so the issue is wrong.
[04:28:02] <adekok> No one has implemented it for replay protection. Requires synchronized time.
[04:28:12] <adekok> Can we remove it, and suggest use of the Nonce attribute?
[04:28:24] <adekok> Joe:
[04:28:36] <adekok> Does the Nonce attribute protect the same problems as Event-Timestamp?
[04:28:53] <adekok> bernard: tries to articulate the problem. You capture a Disconnect-Request && send it again.
[04:29:07] <adekok> NAS doesn't cache authenticator fields... the packet has a valid signature.
[04:29:35] <adekok> Nonce creates freshness, but would it remember the old Nonce-ness from 3 days ago?
[04:29:44] <adekok> Joe: not sure that the nonce helps.
[04:30:10] <adekok> Stephen Hanna: Don't need synchronized times, just remember last timestamp && compare.
[04:30:28] <adekok> Bernard: maybe Nonce doesn't make sense.
[04:31:12] <adekok> Would solve part of 212 && 223.. Take Nonce out & leave event-timestamp in, clarify that the Event-Timestamp is time of original event, so retransmits don't change Identifier.
[04:31:15] <davidbnelson> We do need to clarify that the ID doesn't need to change.
[04:31:35] <adekok> Issues & fixes
[04:31:48] <adekok> (getting new jabber scribe)
[04:32:09] <adekok> Alan presenting on Issues & Fixes
[04:32:18] <adekok> In WG LC
[04:32:31] <adekok> Comments since LC
[04:33:18] <adekok> Acct-Session-ID and Acct-Multi-Session-Id are Text. Always have been that and people have impld it.
[04:33:43] <adekok> Mandated dupl detn now in spec. That's what everybody was doing anyway.
[04:35:13] <adekok> Noted that sessions should be tracked via the State attribute to provide a per-session EAP identifier.
[04:35:29] <adekok> Most people do that already.
[04:35:34] <adekok> Are we done yet?
[04:35:47] <adekok> Alan posted a preliminary -02 draft on his web site.
[04:36:08] <adekok> We'll probably find more RADIUS issues over time but...
[04:36:26] <adekok> This spec has been kicking around for years. Time to ship it.
[04:37:46] <adekok> (done Issues & Fixes).
[04:37:54] <adekok> Mauricio: filter rule draft
[04:38:11] <adekok> finally published -02
[04:38:37] <adekok> three big changes: removed ordering requirements, rule versioning, diameter considerations redone
[04:39:17] <adekok> Bernard: version negotiation?
[04:39:30] <adekok> Mauricio: nope. Capablity / version negotiation is for the future.
[04:40:21] <adekok> 9 issues open: some for years. Need people to review & get closure
[04:40:44] <adekok> Bernard: Maurico posts proposed resolution. If no comments, close the issue.
[04:41:43] <adekok> Issue 130: Diameter considerations. RFC 4675 approach.
[04:42:02] <adekok> open question on value type.
[04:42:14] <adekok> Bernard: what did we use for Filter-Rule (Looking it up)
[04:42:32] <adekok> (comment): Type in Diamer that's filter rule that may be better suited?
[04:42:52] <adekok> Bernard: can someone else look it up? See what Filter Rule document says
[04:43:02] <adekok> Mauricio: publish -03.
[04:43:06] <davidbnelson> Well, Filter Rule was imported from Diaamter, no?
[04:43:23] <adekok> Propose WGLC in -03. Revisit need for radext-redirection && kickstart if still warranted
[04:43:57] <adekok> (Dave: Yes, discussion is what does Diameter say... someone needs to look)
[04:44:35] <adekok> Hannes: looked it up: had discussion in DIME about QoS. Looked at RADEXT work for Diameter compatibility
[04:45:00] <adekok> Hannes: some DIME participants thought that the document is not yet what they would need, but don't have details.
[04:45:10] <adekok> Hannes will solicit comments in DIME tomorrow.
[04:45:26] <adekok> Mauricio: What are there concerns?
[04:46:04] <adekok> Hannes: version is separate issue... match part && action part to do specific behavior. That part needs extensibility, too.
[04:46:25] <adekok> Don't want to change format && version when you add an action.
[04:46:44] <adekok> Bernard: RADIUS Filter-Rule document doesn't have a diameter section, because it was taken from Diameter.
[04:46:50] <adekok> (WLAN attributes)
[04:46:52] <adekok> Bernard:
[04:46:57] <davidbnelson> This brings back the whole discussion of how you know a NAS can act on any of these rules.
[04:47:18] <adekok> Issue 222 & 224: IEEE 802.11 review
[04:47:40] --- joonhyung.lim has joined
[04:47:45] <adekok> Questions. Do we need an SSID?... no.
[04:47:52] <adekok> Mobility domain doesn't need UTF-8
[04:48:11] <adekok> Next steps. Address review comments. Issue -04.
[04:48:26] <adekok> (RADIUS design guidelines)
[04:48:34] <adekok> Bernard:
[04:48:47] <adekok> need for rapid progress. Other documents depend in it, we're not making progress.
[04:48:58] <adekok> Proposal is to apply elbow grease.
[04:49:11] <adekok> Individual submission from Greg weber. Guidelines, etc.
[04:49:28] <adekok> Feedback was that the document should focus on data model && not extend it. Description should be thorough.,
[04:49:33] <adekok> Don't deprecate existing formats.
[04:49:43] <adekok> Articulate design principles.
[04:50:03] <adekok> (pointers to discussion in list archives)
[04:50:27] <adekok> next steps: take out motivation & solution, rewrite section 7, in a way that is consistent with what happens
[04:50:45] <adekok> Expand on data model && VSA data model section.
[04:50:53] <adekok> Need an editor: appy to the chairs
[04:51:25] <adekok> Glen: thinks we was the one assigned the responsibility
[04:51:33] <adekok> Did he edit it?No. (Bernard: shame, shame!)
[04:52:11] <adekok> Glen needs comments & instructions to the editor. He has the XML before he came here.
[04:52:23] <adekok> Will be more than happy to do the editing.
[04:52:40] <adekok> Bernard: try to get proposed text for guidelines section, and hopefully get someone to help
[04:53:01] <adekok> Not going to be a long thing... 5 pages & we're done.
[04:53:13] <adekok> Considering pain we're in for it not being done, that's the better way to go.
[04:53:26] <adekok> Crypto-Agility portion of the agenda
[04:53:37] <adekok> Bernard is channelling Dave
[04:53:53] <adekok> Requirements for crypto agility presentation.
[04:54:28] <adekok> module mechanism to update crypto without substantial disruption
[04:54:48] <adekok> provide for dynamic installation (do we really mean that)
[04:54:57] <adekok> (room hum seems to say no)
[04:55:05] <adekok> Forget those two words..
[04:55:23] <adekok> Ah... RADIUS crpyto-agility is different.
[04:55:45] <adekok> Ability to negotiate crypto for RADIUS, algorithms, messages, etc.
[04:56:17] <adekok> Glen: this is worse than the previous requirement... adapting is easier than negotiating.
[04:56:25] <adekok> Not sure what we mean by negotiation..
[04:56:39] <adekok> Current state of affairs: MD5-based stuff
[04:57:00] <adekok> Md5 collisions does not comprimse RADIUS
[04:57:11] <adekok> MD5 is deprecated
[04:57:25] <adekok> Goals:
[04:57:35] <adekok> develop backward compatible, interopable methods
[04:57:52] <adekok> satisfy mandate from security AD to add crypto-agility to IETF protocols
[04:57:55] <adekok> Process steps:
[04:58:05] <adekok> 1..6.
[04:58:28] <adekok> Call for document, accept one, get consensus.
[04:58:42] <adekok> Doesn't have to be just one document. Publish them all, and let the market sort it out.
[04:58:54] <adekok> Glen: Still wants to know what negotiation means
[04:59:21] <adekok> Would like it to mean "hint and/or separate deny". But that's not negotiation. It's take it or leave it.
[04:59:32] <davidbnelson> Agree, RADIUS negotation today uses hints in teh requests.
[04:59:58] <adekok> Glen: would like to replace the word negotiation with hint/accept text
[05:00:03] <adekok> Will post text to the list.
[05:00:07] <davidbnelson> We don't have "counter-offers" however.
[05:00:15] <adekok> Requirements:
[05:00:29] <adekok> not limited to existing protocols in RFC's
[05:01:14] <adekok> Bernard: it would be nice if old-style Tunnel-Password, etc. could be better protected
[05:01:53] <adekok> Bernard: replay protection for CoA is probably the worst, other messages are less problematic?
[05:01:56] --- gernot has joined
[05:02:23] <adekok> Maybe proposals don't need to support it?
[05:02:39] <adekok> Glen: not sure what this means. Maybe proposal "SHOULD" support replay protection.
[05:02:51] <adekok> Bernard: are we sure that existing methods are inadequate?
[05:03:07] <adekok> post message to list saying we need to get rid of reply protection
[05:03:11] <adekok> (replay protection)
[05:03:31] <adekok> Requirements (cont'd)
[05:03:35] <adekok> backwards compatibility
[05:03:47] <adekok> (Requirements cont'd) again
[05:04:07] <adekok> protection against bidding down attacks: maybe MD5 will be cracked entirely.
[05:04:34] <adekok> Goes back to hiding thing: If we don't use old methods for hiding, then attacks that discover shared secret won't matter.
[05:05:11] <adekok> MUST include a diameter compatibility section/
[05:05:20] <adekok> (why? No one knows...)
[05:05:25] <adekok> Probably isn't relevant.
[05:05:57] <adekok> prohibits changes to radius (new types, formats, packet codes)
[05:06:20] <adekok> (comment from ?) Clarify why proposals are not required to include Diameter compatibility section
[05:06:46] <adekok> Bernard: this has to be supported in a RADIUS to Diameter gateway.
[05:07:13] <adekok> Strictly RADIUS transport. Diameter considerations section says "doesn't affect diameter"
[05:07:57] <adekok> Glen: addition of no new capabilities seems contradictory... we're adding new capabilities.
[05:08:23] <adekok> Bernard: don't include other irrelevant things. Proposal should focus on crypto-agility and nothing else.
[05:08:53] <adekok> (question: Reply protection is out of scope)?
[05:09:05] <adekok> Bernard: we just agreed it's not a problem.
[05:09:41] <adekok> Dave (AD):
[05:10:03] <adekok> important to get progress on this topic. It's nice to talk about the process, but it's more important that we have consensus to get there.
[05:10:17] <adekok> Requirements are nice, it's more important to get work done. It's important, and can't take forever.
[05:10:26] <adekok> We need to get closure.
[05:10:46] <adekok> Bernard: once we get rid of current WGLC's, design guidelines is #1, this is #2.
[05:10:52] <adekok> RADIUS + DTLS
[05:11:00] <adekok> (new scribe)
[05:11:08] <adekok> hi
[05:11:23] <adekok> Preliminary proposal`
[05:11:28] <adekok> outlines issues
[05:11:54] <adekok> we can do better then current "inventive" mechanism
[05:12:17] <adekok> Straigntforward use of TLS
[05:12:28] <adekok> Reuse something that works
[05:13:01] <adekok> Bad parts of TLS involve TCP
[05:13:28] <adekok> TCP works only in some circumstances (perhaps beween proxies)
[05:13:45] <adekok> DTLS - datagram TLS
[05:14:02] <adekok> Latest version of OPenssl supports DTLS
[05:14:30] <adekok> Writing DTLS to RADIUS gateway is harder than it looks
[05:14:51] <adekok> Bernard: would you do DTLS on a different port?
[05:14:58] <adekok> Alan: yes,
[05:15:13] <adekok> DTLS reauires more from RADIUS servers
[05:15:42] <adekok> such as ordered delivery, connections
[05:16:10] <adekok> Duplicate detection and sequence numbers
[05:16:21] <adekok> Recreating TFCP
[05:16:41] <adekok> : Alexus how would you do load balancing
[05:16:55] <adekok> Alan: DLTS session is needed for different servers
[05:17:07] <adekok> Bernard: work done is open SSL?
[05:17:36] <adekok> Alan: DTLS part done in open SSL, connection management etc required in addition to radius.
[05:18:01] <adekok> Benefits: solves crypto agility
[05:18:20] <adekok> May eliminate shared secrets
[05:18:50] <adekok> For purpose of this draft use of certificates is out of scope.
[05:19:43] <adekok> Diameter compatability is not a concern
[05:20:09] <adekok> NBernard if service type is DTLS what happens to other service type.
[05:20:20] <davidbnelson> Why not just use a different port?
[05:20:35] <adekok> Alan: THis service type is jsut use to negotiate use of TLS (Do You use TLS?)
[05:20:44] <adekok> Possible to use different port
[05:21:07] <adekok> DTLS may be complex, however ti solves all the problems
[05:21:28] <adekok> Session tracking is complex, but maybe we can leverage another gorups work (SIP?)
[05:21:53] <adekok> DDTLS code in open SSL assumes only one peer is sending you packets.
[05:22:04] <adekok> (sample code)
[05:22:22] <adekok> you need to do the demultiplexing outside of Open SSL implementation
[05:23:57] <davidbnelson> Negotation (whatever that meand) would be OK, but I think overloading the Service-Type may be a bad diea.
[05:24:16] <adekok> Starting up TLS sessions is expensive, session identifier may require multiple channels
[05:24:45] <adekok> Bernard: When would you need multiple DTLS sessions?
[05:25:32] <adekok> Alan Its not about duplicates, when you proxy packets and you have 400 NASes if every one logs in at the same time you have more identifiers so you need to open another source port on the proxy = new DTLS session.
[05:26:17] <adekok> Joe: session resumption may make DTLS negotiation less expensive
[05:26:37] <adekok> Glen: Little problem with using service type as ngotiation
[05:27:21] <adekok> . If the server doesn't support DTLS the server can take it as a hint, but it doesn't have to do anything. It does not have to treat it as a reject.
[05:28:01] <adekok> Alan: if the server does not understand it then it responds with a different service type if it does support it or an access reject.
[05:28:11] <adekok> Bernard: packet isinthe clear it could be forged
[05:28:43] <adekok> Could be a down grade attack
[05:28:58] <adekok> Different port may mitigat this attack somewhat
[05:29:14] <adekok> Questions
[05:29:15] <davidbnelson> Yeah, I think a different post may be better.
[05:29:21] <davidbnelson> port
[05:29:31] <adekok> ok
[05:29:42] <adekok> (swapping presenter & scribe)
[05:29:52] <adekok> Joe: Keywrap
[05:30:29] <adekok> Goals: securely transport crypto keying material.
[05:30:37] <adekok> provide strong authentication for any RADIUS message
[05:31:35] <adekok> Attributes: keying material, MAC randomizer, Message-Authentication-Code
[05:32:12] <adekok> application id & key lifetime associated with key.
[05:32:37] <adekok> Bernard: Q: interaction with existing Session-Timeout key lifetime?
[05:32:40] <adekok> joe: independent..
[05:33:02] <adekok> Bernard: can't be longer than Session-Timeout, but could be shorter... what does that mean.
[05:33:35] <adekok> Joe: shorter of two would determine it. Probably would want to adjust Session-Timeout down to match key lifetime
[05:34:42] <adekok> Bernard: randomizer is less replay protection than freshness?
[05:35:00] <adekok> Joe: yes. Some tying of request to response, which is different than replay protection
[05:35:20] <adekok> Dan Harkins: freshness for... what?
[05:36:01] <adekok> Joe: freshness might not be the right word. Current CoA has insufficient randomness in packet to differentiate one request from another...
[05:36:33] <adekok> Bernard: randomness is there for MD5 stream ciphers
[05:37:09] <adekok> Dan: AES keywrap doesn't require an additional randomizer because you're assuming that what you're using is random itself.
[05:37:28] <adekok> Dan: randomness of message space is big enough that you don't need additional randomness.
[05:38:09] <adekok> Glen: MAC randomizer used to be called Nonce. It's substituting for the authenticator that makes the message authenticator attribute actually work.
[05:38:27] <adekok> It's not in CoA or Accounting, the random Request Authenticator isn't there.
[05:38:37] <adekok> It makes the Message Authentication Code work.
[05:38:50] <adekok> The MAC randomizer is echoed in response packets.
[05:39:09] <adekok> Bernard: problem in 3576 was a circular dependency
[05:39:47] <adekok> Glen: authenticator is hash of the rest of the message...
[05:40:31] <adekok> The circular dependency is solved, but there's no randomness.
[05:40:51] <adekok> Alan: solving circular dependency is different than solving randomness that doesn't exist in Accounting-Request
[05:41:24] <adekok> Glen: it's a naming problem... it happens to be a random number, but it's a nonce... not really.
[05:41:35] <adekok> Rationale:
[05:41:51] <adekok> extends RADIUS framework, re-usable in various situations.
[05:42:38] <adekok> Features:
[05:42:52] <adekok> no key management provided. Keys "magically" provisioned.
[05:43:07] <adekok> No reliance on particular derivation methods.
[05:43:20] <adekok> application Id identifies key usage.
[05:43:31] <davidbnelson> How do we get interoperability without specifying the "magic"?
[05:43:35] <adekok> Crypto-agility is supported. Encryption & MAC algorithms are replaceable.
[05:43:37] <adekok> Summary:
[05:43:51] <adekok> provides crypto-agility for message authentication
[05:44:15] <adekok> Provides crypto-agility for common key encryption attributes
[05:44:26] <adekok> Efficient. Only necessary keys encrypted, not whole attribute.
[05:44:46] <adekok> Dan: whole bunch of key Id's, all completely unspecified. Looks like giant covert channel is being specified.
[05:45:12] <adekok> Doesn't seem that a RADIUS client & server would share 2 different keys for same purpose
[05:45:42] <adekok> Joe: don't include key management scheme. Seems to be useful to provide way to identify keys
[05:45:49] <adekok> e.g. manual roll-over keys.
[05:45:54] <adekok> Hannes: common practice
[05:46:07] <adekok> Bernard: it's in DNS SEC, and people are questioning why it's there.
[05:46:26] <adekok> Joe: key management needs to name keys. Could be implicit.
[05:46:51] <adekok> Dan: naming of keys is important, Housley criteria says you have to do this, but those are keys used by endpoints.
[05:47:04] <adekok> RADIUS is just a transport, and doesn't need to identifiy the keys.
[05:47:24] <adekok> Specification of the content of the key Id's is outside scope, don't need them, create a VSA.
[05:47:47] <adekok> Joe: key management is outside scope. Interoperable implementations work with manually entered keys & key Ids.
[05:48:22] <adekok> Hannes: regardless of where the protocols run, you still need key naming. Key identifiers are opaque, set by outside means, that's done in many working groups.
[05:48:38] <adekok> Joe: key management scheme would be good to develop. Key Id's could be zero for all I care
[05:48:53] <davidbnelson> Develop or reference an existing one?
[05:49:03] <adekok> Dan: naming a key is important, RADIUS is just a transport. Name has to be known by user & generator of keys, why does RADIUS care?
[05:49:11] <adekok> (dave: i'll get the mike)
[05:49:52] <adekok> (Joe, Bernard, Dan lots of fast discussion)
[05:50:31] <adekok> Dan: how do I process this? what if it doesn't make any sense in the context of a RADIUS client?
[05:50:40] <adekok> Joe: you don't have a key..
[05:50:59] <adekok> Hannes: in EAP, you have an identifier, and name the key.. many examples of where this is done.
[05:51:11] <adekok> (RCP?)
[05:51:28] <adekok> Bernard: spec for key naming exists. RFC 4072, which exists a standard for RADIUS & Diameter.
[05:51:43] <adekok> Joe: That's fair. You could be transporting keys other than EAP keys.
[05:51:54] <adekok> Bernard: adds new functionality beyond RADIUS.
[05:52:05] <adekok> Joe / Glen: No. Existing keys could be used to send anything.
[05:52:20] <adekok> Bernard: Diameter standard is EAP-MSK, but can't be transported in RADIUS.
[05:52:37] <adekok> 4072 can't transport arbitrary keys in arbitrary contexts.
[05:52:49] <adekok> Joe: can transport keys beyond EAP.
[05:53:14] <adekok> Glen: Wonderign why this is incompatible with naming scheme. Huge covert channel for anything...
[05:53:33] <adekok> Bernard: existing attribute defined in RADIUS for EAP.
[05:53:48] <adekok> Glen: change draft so that if application type is EAP-MSK, then key ID doesn't exist.
[05:53:57] <adekok> Joe: these are all good comments.
[05:54:13] <adekok> Different from DTLS approach, has its own problems and benefits.
[05:54:24] <adekok> Bernard: comments about keying, not crypto-agility. Focus on that.
[05:55:25] <adekok> Hannes: comment on key management. Posted email to list. Manual config, leverage IKE work with domain of interpretation, new type of approach, which leverages domain of interpretation to ... (?) combine DTLS proposal, and derive keys to use for this purpose
[05:55:50] <adekok> Dan: IKE's DOI is a perfect example of why it's a bad idea. I'm sorry I put it in there. It's always the same, nobody ever change it.
[05:56:28] <adekok> Good idea to AES-keywrap keys, core idea is great, but has excess baggage.
[05:56:40] <adekok> Bernard: any issues with crypto-agility portion?
[05:57:04] <adekok> Alan: how does this address Tunnel-Password, etc?
[05:57:22] <adekok> Glen: it doesn't. There's another draft about encrypting attributes does address it.
[05:57:58] <adekok> Other draft concatenates one or more attributes, encrypts them, and sends them. Can use almost any algorithm you want.
[05:58:08] <adekok> Joe: default was AES-CBC.
[05:58:18] <adekok> Bernard: for passwords, don't have to use keywrap.
[05:58:52] <adekok> Bernard: other doc would do User-Password, etc. Would be required with this draft to satisfy crypto-agility.
[05:59:01] <adekok> Glen: will send email asking for other draft to be considered:
[05:59:20] <adekok> Hao: standardize encrypting attribute separate form randomizer?
[05:59:40] <adekok> Bernard: keep key document separare from crypto-agility, move crypto-agility work to encrypting document.
[06:00:34] <adekok> Glen: Not sure how you'd do that. crypto-agility is part of attribute.
[06:01:20] <adekok> Bernard: negotate cipher suite as part of keywrap? Can separatelty negotiate key & attribute encryption
[06:01:20] <adekok> Glen: OK
[06:01:43] <adekok> Dan: There's an IV defined.. why?
[06:02:20] <adekok> Joe: for AES-keywrap, don't need to define an IV, because AES-keywrap defines an IV. IV could be part of the encrypted data structure...
[06:02:47] <adekok> Next steps:
[06:03:10] <adekok> Draft in rev 12, extensively reviewd, approach vetted by NIST, multiple interoperable implementations Cisco, 3eTI)
[06:03:26] <adekok> Hao: are we all OK with requirements?
[06:03:36] <adekok> Bernard: Glen will post changes to list.
[06:04:04] <adekok> Will use updated requirements to evaluate proposals. We don't have to pick just one.
[06:04:28] <adekok> Ask submitters to address requirements, maybe in draft, maybe elsewhere
[06:04:45] <adekok> RADIUS prepaid draft:
[06:05:11] <adekok> Should this go forward as informational using VSAs?
[06:05:28] <adekok> Want people to read the draft. Please spend the last 15 minutes reading the doc & posting to the list.
[06:06:25] <adekok> Hannes: got frustrated with lack of protocols. It's use by 3gpn & WiMAX. Would like to publis & document what's out there.
[06:06:40] <adekok> Would be OK to do uit.
[06:06:45] <adekok> We have editor.
[06:07:08] <adekok> Bernard: write it up, submit it as informational. WG can review it.
[06:07:16] <adekok> Hannes: will submit right after IETF.
[06:07:30] <adekok> Bernard: call for items none. Go read RADIUS extensions draft.
[06:07:34] <adekok> Thanks. Done.
[06:08:01] --- adekok has left
[06:08:06] --- davidbnelson has left
[06:12:24] --- kasumigaura has left
[06:27:36] --- afh@jabber.netzwert.ag has left
[06:53:20] --- gernot has left
[08:49:32] --- joonhyung.lim has left
[09:11:58] --- joonhyung.lim has joined
[09:45:36] --- joonhyung.lim has left
[10:42:12] --- LOGGING STARTED
[11:31:42] --- joonhyung.lim has joined
[14:27:47] --- joonhyung.lim has left