[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] RE: AuthenticationMethod / NameIdentifier and Kerberos authentication
Correct. In our document we have to find a way to mention that each pre-auth type is described in the appropriate draft/rfc. In future IANA will be used, but I don't know what timeframe. There is also a list in the clarifications document of pre-auth types that were current when this document was last changed. I do have a few useful emails which are from IETF discussions on this subject - see below : ------------------- Tim> Hi, Can somebody let me know whether there is a reliable and Tim> uptodate list of padata-type numbers, and if so where ? I see Tim> references to some in rfc1510 and some drafts contain Tim> references to padata-type numbers, so I wondered how somebody Tim> defining a new authentication method would determine if a Tim> number was not being used elsewhere ? The list in clarifications should be accurate. Along with extensions we will be setting up an IANA registry. If you wish to use a padata for local use or for any other unregistered use, then use a negative type number. Simply using some unused padata type would not be reasonable. If you do need to register a padata type, ask Cliff for now; again this will eventually be handled by the IANA. ------------------- > The reason for asking is that I am working with another standard (not > IETF controlled) that will make reference to the Kerberos standard, so > I want to make sure if we mention rfc1510 that this rfc number is > going to be the correct rfc in the future. If I understand you > correctly, a new number will be allocated when clarifications is > approved by IESG so we should make this clear in our documentation. That is correct. RFC's are immutable; once published, an RFC never changes (the rfc-editor does maintain a list of errata in published RFC's at http://www.rfc-editor.org/errata.html, but the originial documents are never modified). RFC1510 describes Kerberos V, Specification 1. Once approved, kerberos-clarifications will be published as a new RFC; this will obsolete RFC1510 and (in combination with the crypto and AES documents) will describe Kerberos V, Specification 2. In most cases it is desirable in a standards context for normative references to be to a particular version of the specification. For IETF standards, you can do this by referring to a particular RFC. In a few cases, you actually want a reference to "the current version", whatever that happens to be. The IETF way to do this is to refer to an STD number; however, these numbers are currently assigned only to full Internet standards. -- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ------------------- Thanks, Tim. -----Original Message----- From: John Kemp [mailto:john.kemp@nokia.com] Sent: 04 June 2004 14:00 To: Tim Alsop Cc: Linn, John; p.madsen@entrust.com; security-services@lists.oasis-open.org Subject: Re: [security-services] RE: AuthenticationMethod / NameIdentifier and Kerberos authentication So, given the state of the Krb specification, I guess its also the case that there is no currently defined list of the actual pre-auth methods, even though it is planned that there will be one (some day) listed by IANA? - JohnK ext Tim Alsop wrote: >This sounds ok to me. I think it would make good sense to mention >clarifications as 'work in progress' using the approach you indicated. >It is however important to mention it in some way because many people >make the mistake of looking at rfc1510 to find out about Kerberos and >don't realise this isn't the latest definition of the protocol. > >Cheers, Tim. > >-----Original Message----- >From: Linn, John [mailto:jlinn@rsasecurity.com] >Sent: 04 June 2004 13:49 >To: Tim Alsop; John Kemp >Cc: p.madsen@entrust.com; security-services@lists.oasis-open.org >Subject: RE: [security-services] RE: AuthenticationMethod / >NameIdentifier and Kerberos authentication > >Tim wrote, excerpting: > > > >>The Kerberos protocol is (as you know) defined in IETF RFC1510, however >>(you probably didn't know) it is now defined in a IETF draft called >>Kerberos clarifications which obsoletes RFC1510 (see >>http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kerberos-clarifi c >> >> >a > > >>tions-05.txt). Our documentation needs to reference this correctly. >> >> > >Per the last sentence, this is true but can sometimes be a tricky thing >to >accomplish. As the general discussion of Internet-Drafts as a document >type >(http://www.ietf.org/ID.html) states, "Internet-Drafts are not an >archival >document series. These documents should not be cited or quoted in any >formal >document. Unrevised documents placed in the Internet-Drafts directories >have >a maximum life of six months. After that time, they must be updated, or >they >will be deleted." > >IETF discussion of revisions and successor drafts to RFC-1510 has been >ongoing at least since 1997; while the current clarifications-05 draft >has >been forwarded to the IESG as a candidate for advancement to RFC, I >haven't >yet seen any IESG advancement action reported on it. As such, it's >still >possible that further changes will take place before publication of any >subsequent RFC. One common way to handle this in bibliographies is to >cite >something like "<title of document>, work in progress, IETF <nnn> >working >group, date.", but (by intent) there's no archival reference that can be >assumed stable until RFC publication takes place. > >--jl > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]