Re: [HOKEY] Oversight in key management draft

["Glen Zorn" <gwz at net-zen.net>]

Hoeper Katrin-QWKN37 [mailto:khoeper at motorola.com] writes:

> > Glen Zorn [mailto:gwz at net-zen.net] writes:
> >
> > > Hi, Katrin.  While doing a final review as part of the document
> > > shepherding
> > > process, I noticed what I think is an oversight that may have
> occurred
> > > while
> > > removing the RADIUS-specific stuff from the draft: section 4 says
> "The
> > > following key types are defined: 0 (DSRK), 1 (USRK) and 2
> (DSUSRK)."
> > > This
> > > seems out of place now.
> >
> [KH]
> The Key Request Token (KRT) carries (among other things) the key type
> of
> the requested key. In the draft we specify three keys that can be
> requested/delivered, i.e. DSRK, USRK and DSUSRK.
> 
> For that reason I thought it still makes sense to assign those numbers
> to identify these keys, independent of which AAA protocol is used.

OK.  Why?

> 
> Do you think it should be left to the implementers to define the key
> types?

I think that the key types have been defined in other documents, including
types not mentioned in this note; I'm not sure of the benefit of having a
single set of numbers across all AAA protocols, but that's just me.

> If so, should we provide any guidance on this in the draft?
> 
> > As does the IANA Considerations section & BTW, remind me why this is
> > Standards Track instead of a BCP...
> >
> [KH] Sorry, I cannot remind you, 

Sorry, it was more a question for the WG at large; I wasn't trying to put
you on the spot.

> because when I became the new editor
> of
> this document this decision was already made and I cannot recall any
> discussions on this topic. What do previous contributors think about
> this?
> 
> I think changing it to BCP might be a good idea, given that we do not
> know any current implementations that use the KDE protocol defined in
> the draft.

Well, the protocol is (rightly, I think) quite abstract, but other work is
being done (e.g.,
http://www.ietf.org/internet-drafts/draft-wu-dime-local-keytran-02.txt).

> 
> 
> > > If it is an error, do you want to fix it now
> > > or
> > > wait for IETF Last Call?
> > >
> > > ~gwz
> > >
> > > Play assigns meaning to human activity--work erases it.
> > >   -- P.L. Wilson
> > >
> > >
> > >
> >
>