RE: [security-services] RE: AuthenticationMethod / NameIdentifier and Kerberos authentication

["Tim Alsop" <Tim.Alsop@CyberSafe.Ltd.UK>]

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
>
>
>  
>