[10:10:03] --- nico has joined
[11:02:37] --- tlyu has joined
[11:23:20] --- larry has joined
[11:45:26] --- DaveChristiansen has joined
[11:46:51] --- lha has joined
[12:05:07] <lha> nico, our current scribe doesn't take notes into jabber
[12:05:10] <lha> feel free to call in
[12:06:01] <nico> oh well
[12:06:06] <nico> I have to go soon
[12:06:59] --- raeburn@jis.mit.edu has joined
[13:00:16] --- hartmans has joined
[13:26:00] --- MWChapel has joined
[13:27:47] <hartmans> I so should have said that sooner.
[13:31:23] --- Venkat has joined
[13:34:12] --- Jeffrey Altman has joined
[13:34:28] --- Venkat has left: Disconnected
[13:36:14] --- Venkat has joined
[16:26:12] --- Venkat has left: Disconnected
[16:30:20] --- Venkat has joined
[16:41:31] <Jeffrey Altman> if we rev 4121 we should remove support for the "no subkey" case.
[17:01:28] --- MWChapel has left: Disconnected
[17:22:53] <Jeffrey Altman> The event is at 7:00pm at the Desert Fire restaurant in Redmond Town Center. The reservations are under 'Microsoft' and the address is 7211 166th Ave NE, Redmond, WA 98052. My cell is 425-301-2277 in case there are any problems. http://yp.yahoo.com/py/ypMap.py?Pyt=Typ&tuid=26281164&ck=3937832649&tab=B2C&tcat=8903827&city=Redmond&state=WA&uzip=98052&country=us&msa=7600&cs=4&ed=yNQjoa1o2TzCqJrV2uFiyG6GDRdNYAZta3cyB8qBk7gXmw--&stat=:pos:0:regular:regT:1:fbT:0
[17:24:06] <Venkat> that's the message from JK
[17:41:40] <DaveChristiansen> Now we're talking about KerberosString. I'm unclear as to the context...
[17:45:12] <Jeffrey Altman> KerberosString does not include context specific tags. This is not to reduce size but because they are not necessary for this object.
[17:45:13] <DaveChristiansen> Clarification as to why there haven't been tags all over the place in RFC1510: because we could get away without adding two bytes to every message.
[17:45:28] <DaveChristiansen> (requested by lzhu)
[17:45:54] <DaveChristiansen> ahh, ok.
[17:48:35] <DaveChristiansen> quick dump:
[17:48:38] <DaveChristiansen> KerberosString ::= CHOICE { ia5 GeneralString (IA5String), utf8 UTF8String, ... } KerberosStringIA5 ::= KerberosString ( WITH COMPONENTS{ ia5 PRESENT } ) KerberosStringExt ::= KerberosString ( WITH COMPONENTS{ ia5 ABSENT } )
[17:49:08] <DaveChristiansen> Tlyu says: what do we do instead of KerberosString today
[17:49:44] <DaveChristiansen> "KerberosStringExt is not useful except in very specific places, but we should find out where those are...
[17:51:00] <DaveChristiansen> 3 choices:
[17:52:10] <DaveChristiansen> 1. use unconstrained type today 2. types shared between protocols get unconstrained choice types; specific to the old protocol get legacy, new protocol get nonlegacy string types 3. explicitly split out all types as having either the old protocol or the new (Dave: ugh)
[17:54:05] <DaveChristiansen> --> Are there new messages that require the old String?
[17:57:16] <DaveChristiansen> Sam: much better if a PDU is either old or new, and new PDUs don't include Old-style strings This will require that some fields may become separate PDUs
[18:01:10] <DaveChristiansen> Sam's proposal is that string encoding be handled at the level above ASN.1. Tom: how about old PDUs? ... Sam: I think this depends on the whole "shared types" thing that we've never come to grips with. If ticket-ext is different from 1510 then I don't care. Jeff: if they're different, then are we updating 4120 or are we obsoleting? [many] obsoleting Tom: ...we need to show how to use elements of 4120 in a backward-compatible mode. Otherwise, messy. Jeff: will people get pissy if the modules change? Sam: different module == different oid Jeff: Some documents will reference the document-- if the elements change, they may update without realizing they're changing the semantics of their protocol. Tom: does that mean we use new typenames? Jeff: ... KerberosString might be one of them. Sam: I would prefer there be only one. If Love disagrees with me then I'm wrong.
[18:01:27] <DaveChristiansen> Sam's proposal is that string encoding be handled at the level above ASN.1. Tom: how about old PDUs? ... Sam: I think this depends on the whole "shared types" thing that we've never come to grips with. If ticket-ext is different from 1510 then I don't care. Jeff: if they're different, then are we updating 4120 or are we obsoleting? [many] obsoleting Tom: ...we need to show how to use elements of 4120 in a backward-compatible mode. Otherwise, messy. Jeff: will people get pissy if the modules change? Sam: different module == different oid Jeff: Some documents will reference the document-- if the elements change, they may update without realizing they're changing the semantics of their protocol. Tom: does that mean we use new typenames? Jeff: ... KerberosString might be one of them. Sam: I would prefer there be only one. If Love disagrees with me then I'm wrong.
[18:03:34] <DaveChristiansen> Love prefers an inline approach; codesharing. Larry: Could this all be done by the ASN compiler? Love: no. If constraints can be expressed as constraints, that's okay, but it must be readable. Other people must be able to understand the document to get 3rd party review. So I would be fine with Sam's proposal.
[18:11:01] <DaveChristiansen> Discussion as to whether ASN constraints are easier to read than text. Tom: easier to machine-parse, if you do that. Jeff: We do have difficulty that we've chosen to use a language that trades readability for function. Love: the compiler enforces constraints. What constraints? If the user doesn't understand the constraints when written, what does the compiler enforce? The user may mis-specify. "Do we want what we're writing?" - Love Tom thinks so, but knows ASN1 better than we probably do. Jeff: there may be constraints too complex to implement as Constraints, so trying to do so would be a mistake. Larry agrees. Jeff: example: KDC_REP_PART for which the case included in the KDC_REP_PART is an old-style ticket for a service with a legacy-encoded name. There's no way to write an ASN1 constraint on that principalname that constrain the name to be an ia5 string. You could write freeform comments to do this, but they'd be (at worst) no better than the text. Tom: there are places where constraints specific to prohibit/bless legacy strings would be useful. Jeff: 3 approaches. 1. new types for each message that happen to look alike 2. foreach message define a common type then define new and old containers with constraints 3. define a common type that can go either way.
[18:14:01] <DaveChristiansen> need a way to make constraints more obvious. #3 makes everything hard. Love proposes that we write this stuff down. I add that many people should do this in jabber so I don't have to [poorly] transcribe it.
[18:32:47] <DaveChristiansen> Sam: this is maybe the 6th time we've talked about this, and this group is not necessarily represented. Love: we don't need to decide here-- we just have to write our stuff down so we can reach consensus elsewhere. Jeff: can we consider the smaller types like strings separate from the larger pdus?
[18:34:12] <Jeffrey Altman> Minutes from IETF Interim Meeting at Cable Labs (9/17/2003) Tom begins presentation “Syntax and Encoding for Extensibility” 9:00am A demonstration of extension markers. “[[“ and “]]” brackets are part of the notation used to wrap the extended fields. RELATIVE-OIDs allow for more compact representation on the wire. The Base OID is not included in the ASN.1. There is no ability to use the ASN.1 compiler to enforce relativity to a given base. When would a typed hole be used instead of a new field? New fields can only be created by IETF action to revise the Kerberos protocol. However, typed holes are the preferred mechanism for extending the protocol without requiring protocol revisions. Authenticated Cleartext: a checksum will be used to protect a new InnerType by signing the InnerType with the available key. This data structure is optional because we do not always have a key available during all instances we need to send a KRB_ERROR at. Signed is extensible because we are being conservative about making sure we always have a means of extending constructs whenever possible. There is a desire to rename Signed to something else to make it be less ambiguous as to whether it is a base ASN.1 type or not. On the “Shared Encoders” page the field bar should be constrained to be ABSENT in the Foo-1510 SEQUENCE. There is an extraneous comma after the extension marker in Foo-Common. This discussion applies to both hand and machine generated ASN.1 encoders for the Kerberos messages. The use of shared encoders will reduce costs and errors. MIT does not have script for auto-generating the separate encoders from the shared encoders at the current time. We anticipate that high end ASN.1 compilers provide these transformations. Microsoft requests that none of the new ASN.1 syntax be used. JHutz explains how the shared encoders can be used to generate independent encoder input for both 1510 and Extensions. Perhaps we should include expanded ASN.1 modules as an Appendix to the Extensions document. Informational Parameters / Constraints. The WG has done a poor job in the past of identifying which keys or key usage values should be utilized when encrypting any particular piece of encrypted data. Larry: Why is the ‘kvno’ in EncryptedData not protected by the checksum? There is agreement that the lack of the “kvno” is a defect which should be fixed in Extensions. Larry: It is possible to have multiple keys for the same Enctype, why does EncryptedData not take this into account? This is an issue for Microsoft because they use password based Service keys. This is not an issue for keytab stored Service Keys. Perhaps the EncryptedData should contain a salt-string. Sam believes that passwords should not be used for service keys instead of adding new fields to EncryptedData. Why should PK-CROSS be a Ticket extension versus an EncryptedData extension? The EncryptedData field only contains the minimum information needed to decrypt the data minus the key. It seems like other required information could be added. PK-CROSS is a protocol extension and its operations are unique to a Ticket. EncryptedData extensions should be more general. Lots more discussion. Discussion of Microsoft’s requirement to use StringToKey on service keys should be brought to the list. Information Objects allow us to formalize how holes are used in the protocol. “@” binds the element in padata-value must match the id-int in padata-type. The TYPEDHOLE definition utilizes the WITH SYNTAX mechanism for defining our own user readable syntax for specifying typed holes. Microsoft supports the use of the IOS however there is significant concern regarding the use of ASN.1 syntax which has not previously been used due to the use of internal ASN.1 compilers which have not been verified for the previously unused syntax. All of the proposed extension syntax is accepted provided that simplified forms of the ASN.1 modules are provided. The working group needs to find someone with a really good modern ASN.1 compiler to use for verifying. (including expansion of parameterized types.) BREAK The group desires KRB-SAFE functionality similar to GSS-GET-MIC. (in case it was not in yesterday’s notes) We want to make it such that KRB-ERROR Pre-auth failed contain PA-DATA. Option Flags are to be non-critical. A question to be answered closer to publication: “must applications support version 1 tickets”? We need a new typed hole in the authenticator with traditional criticality (ie, NOT CRITICAL) We need a new critical container for Ticket Extensions. Mandatory to implement. We want 64-BIT Sequence numbers. The group has entered a rat-hole while discussing the use of “nonce” within the Kerberos protocol. The nonce is used to bind a reply to a request; and it is also used to prevent replays. It is an open issue to determine whether the integer nonce should be increased in length. Larry proposes a random value of 16-bytes in length. (octet-string 8..32). This is implemented as a contstrained choice. For next Kerberos meeting avoid conflicts with: SASL, SECSH, SAG, IPSEC, APP-OPENAREA, LDAP, NFSV4 LUNCH
[18:46:27] <nico> thanks for the scribing!!
[19:28:02] --- hartmans has left
[19:57:24] --- raeburn@jis.mit.edu has left: Disconnected
[20:02:08] --- tlyu has left: Logged out
[20:06:08] --- lha has left
[20:08:33] --- Venkat has left
[20:20:21] --- Jeffrey Altman has left