Subject: [Ietf-krb-wg] The state of anonymous

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 01 Oct 2008 17:21:41 -0400

We have very nearly come to conclusion on anonymous.  I'm including an 
updated copy of the issue list below; a far as I know there is only one 
outstanding issue.  Once we have resolved that issue, we will begin a new 
WGLC on this document, and if/when that is resolved, I will ask Tim to do a 
new IETF last call.  Ideally, the new WGLC will be resolved before the next 
IETF meeting.

If anyone knows of issues which are not listed in the issue list or which 
they feel are _not_ resolved, please let me know so we can get them taken 
care of before the last call.

The remaining open issue I know of is A030, regarding the question of 
whether we should specify a standardized way of requesting 
partially-anonymous credentials and contexts or leave it up to 
implementations.  We seem to still be divided on that question.  I would 
like to ask anyone who has a position on this issue to restate whether you 
think we should or should not standardize this, and why.  I think this will 
help everyone to understand each other's positions, and it will certainly 
help me to make sure I know where we are on this.

-- Jeff

**********************************************************************
*** OUTSTANDING
**********************************************************************

* A030 Aug 22 Jeffrey Hutzelman <[email-masked]>
  >>    while the use of an anonymous principal with
  >>    a non-anonymous realm by the initiator/client is based on
  >>    implementation specific local policy.
  >
  > What does this mean?
  > What behavior is this talking about?
  >
  > The phrase "implementation specific local policy" is unclear -- is the
  > behavior implementation-defined or is it controlled by policy?

  @ I am not sure if this is a rhetoric question but I answer it any
  @ way: this talks about how to invoke your GSS-API to use an anonymous
  @ principal with a non-anonymous realm  is left to the implementation
  @ because such kinds of names do not correspond to GSS_NT_ANONYMOUS.

  > OK, now I understand [proposes text]

  [[ Lots more discussion on this and A023 ]]

  <jhutz> proposes resolution

  [[ Asof 1-Oct-2008, still no resolution on the question of whether
  [[ to specify a standardized means of requesting partially-anonymous
  [[ credentials and contexts or leave it up to implementations.

**********************************************************************
*** PENDING
**********************************************************************

* A004 Mar 03 Paul Leach <[email-masked]>
  > Why is it necessary to have three ways to specify the crealm in an
  > anonymous ticket?

  @ Related to misunderstanding in A001, but [clarification proposed]
  [[ Text present in -07 ]]

  <hartmans> What controls whether you end up with the wellknown
  <hartmans> anonymous realm or something else?
  @ Based on local policy; issuing KDC decides whether to disclose realm.
  <hartmans> That is not clear from the document; I thought...
  <hartmans> - anonymous PKINIT AS_REQ => well-known realm name
  <hartmans> - anonymous TGS_REQ to local KDC => that KDC realm
  <hartmans> - anonymous TGS_REQ to remote KDC => client or remote realm
  <hartmans> concerned that making this policy interacts badly with GSS
  @ It is up to policy [quotes text], but your interpretation turns out
  @ to be what the protocol allows.  Interactions with GSS are no worse
  @ than with referrals; KDC determines what the client's name is in both.
  [[ A016 would make this clear for the anonymous PKINIT case ]]
  [[ Applying A016 should result in removing the new text ]]

  [[ The restructured text in -08 mentioned in A005 below seems to
  [[ answer all of these questions.
  [[ PENDING resolution of A005 ]]

==============================

* A005 Mar 03 Paul Leach <[email-masked]>
  > Multiple usage modes:
  > - client discloses identity to KDC, but not service
  > - client discloses identity to neither KDC nor service
  > - with or without crealm in ticket
  > The motivation/need for these is not described; the abstract doesn't
  > even hint at their existence.  Can an implementation do just the
  > first?  It would help to be explicit about the mode, and separate
  > section 4 into two sub-sections, one for processing anonymous AS_REQ
  > and one for TGS_REQ.

  [[ -08 includes a rather significant restructuring of section 4 which
  [[ does make the document easier to read but unfortunately does not
  [[ address the question of motivation or of whether an implementation
  [[ must support all possible modes to be compliant.

  [[ doesn't really talk about motivation, still, but if no one else
  [[ cares, will defer to Paul Leach who raised this issue.

  [[ -09 resolves the question of what is required to be compliant ]]

  [[ proposed rewritten abstract
  @ new abstract accepted
  [[ PENDING WG approval ]]

==============================

* A018 Apr 04 Sam Hartman <[email-masked]>
  > If I use pkinit for an anonymous AS request, what should the client
  > realm be.  As I read the draft, the only valid answer is the anonymous
  > realm.  However as Ken Raeburn read the draft, the KDC could use
  > either its realm name or the realm name of the anonymous realm.  I had
  > assumed that you only got the realm name of the KDC or client in cases
  > where TGS requests were used to get anonymous tickets.
  [[ A016 answers this ]]
  [[ Not really; there was a proposed change in the A016 thread that
  [[ addresses this but not A016, which I am copying to here.

  @ Offline discussion... propose to fix this by requiring the returned
  @ realm name MUST be the anonymous realm when anonymous PKINIT is used.
  @ This seems to resolve A016, pending WG consensus.
  [[ New requirement appears in -07 ]]
  [[ PENDING WG approval ]]

==============================

* A022 Apr 07 Ken Raeburn <[email-masked]>
  > First, the GSS-API concept of anonymous session establishment seems to
  > be that the client isn't authenticated at all.  In the WELLKNOWN/
  > ANONYMOUS@SOME-REALM case, *if* anonymous AS requests can only use WK/
  > A@WELLKNOWN:ANONYMOUS as the client name (see Sam's email), then we're
  > giving the server information about the identity of the client.  Maybe
  > not the client's full identity, but at least the realm name.  Should
  > it be treated as anonymous authentication at the GSS-API layer
  > (GSS_C_ANON_FLAG, NT-ANONYMOUS), or not?  The text in krb-wg-anon does
  > imply that realm names may be included in NT-ANONYMOUS names, when
  > discussing the exported name format, but does this match the GSS-API
  > concept of anonymous security context establishment?

  [[ Proposed text in -08 appears to answer this question.
  [[ PENDING WG approval ]]

==============================

* A023 Apr 07 Ken Raeburn <[email-masked]>
  > Should importing an anonymous Kerberos principal name and calling
  > display_name get NT-ANONYMOUS back as the type, or should NT-ANONYMOUS
  > names only be generated by accept_sec_context?

  @ Implementation-specific; no text needed.

  <hartmans> agree

  <mrex> it is mechanism-specific but should not be implementation-specific;
  <mrex> we need to specify the form to be used.

  [[ We seem to have consensus to use GSS_C_NT_ANONYMOUS with a display
  [[ string as described for GSS_KRB5_NT_PRINCIPAL, and that mechanism
  [[ implementations may not localize.  I have made this assertion on
  [[ the list as of 1-Oct-2008 and will wait a short time for objections.
  [[ PENDING objections or WGLC ]]

==============================

* A028 Jul 27 Jeffrey Hutzelman <[email-masked]> (as shepherd)
  > Looking at the first full paragraph on page 7, it appears that a
  > change in requirement level has crept in since the version we
  > sent to IETF last call.  In -05, the KDC MAY remove the
  > AD-INITIAL-VERIFIED-CAS according to local policy; in -07 this
  > has been changed to a SHOULD.  This is a substantive change for
  > which I don't recall any discussion or a consensus.
  [[ Discussion in dublin indicated some support.
  [[ PENDING WG approval ]]

==============================

* A029 Jul 30 Martin Rex <[email-masked]>
  > What about anonymous Kerberos tickets:
  >
  >  - Could there be or are there going to be any identifiers in the ticket
  >    that will allow to "uncover" the principal who originally obtained
  >    the ticket?
  >
  >  - Should anonymous-tickets be limited to single-use (i.e. not be 
cached),
  >    so that independent sessions are not automatically correlated
  >    by repeated use of a cached anonymous service ticket.

  [[ Part A looks resolved in -09 ]]
  [[ Part B may still need security considerations ]]
  <jhutz> proposes text for B
  @ addition accepted
  [[ PENDING WG approval ]]

**********************************************************************
*** RESOLVED
**********************************************************************

* A001 Mar 03 Paul Leach <[email-masked]>
  > client's realm is always exposed to server via transited realm; this
  > makes being truly anonymous difficult.  Why must anon realm not be
  > used in transited realms?

  @ This understanding is incorrect [change proposed]
  [[ Subsumbed by moving the relevant text to Section 4 per A009 ]]
  [[ RESOLVED - EDITORIAL ]]

==============================

* A002 Mar 03 Paul Leach <[email-masked]>
  > The fact that the client's realm is always exposed whouls be noted
  > in security considerations

  @ Skipped, based on incorrect A001
  [[ RESOLVED - N/A ]]

==============================

* A003 Mar 03 Paul Leach <[email-masked]>
  > Why is policy needed on KDC to decide whether the crealm in a service
  > ticket is the anonymous realm or the realm of the KDC?  It seems
  > pointless given A001

  @ Skipped, based on incorrect A001
  [[ RESOLVED - N/A ]]

==============================

* A006 Mar 03 Paul Leach <[email-masked]>
  > In section 2 paragraph 2, suggest changing
  > "if the client wishes to authenticate the KDC anonymously"
  > to
  > "If the client does not wish to disclose its identity to the KDC,
  > yet still authenticate the KDC"

  @ Agreed
  @ Except not; this changes the meaning. [alternate text proposed]
  [[ Alternate text appears in -07 ]]
  [[ RESOLVED - MINOR SUBSTANTIVE ]]

==============================

* A007 Mar 03 Paul Leach <[email-masked]>
  > Why is it interesting to want to remove AD-INITIAL-VERIFIED-CAS from
  > an anonymous ticket?

  @ Clarification proposed
  [[ New text appears in -07 ]]
  [[ RESOLVED - MINOR SUBSTANTIVE ]]

==============================

* A008 Mar 03 Paul Leach <[email-masked]>
  > (re section 5) if an anonymous TGT was obtained, should the client
  > Kerberos library always set the anonymous flag in the KDC options
  > of a TGS request, even if the application does not assert the
  > anonymous flag when calling GSS_Init_sec_context?

  @ Already answered in section 4 [existing text quoted]
  [[ RESOLVED - N/A ]]

==============================

* A009 Mar 03 Miguel Garcia <[email-masked]> (for Gen-ART)
  > - Section 3 1st paragraph says:
  >
  >     An anonymous Kerberos realm name MUST NOT be present in
  >     the transited field of a ticket.
  >
  > and later the third paragraph says:
  >
  >     Note that in this specification, the anonymous principal name and
  >     realm are only applicable to the client in Kerberos messages, the
  >     server MUST NOT be anonymous in any Kerberos message.
  >
  > It came to my attention that this text is part of Section 3: 
"Definitions".
  > However, the above paragraphs are not definitions, but normative text. I
  > would have expected that the Definitions section contains informative
  > definitions that help to understand the draft, but not the normative
  > procedures. I suggest to move the above text elsewhere in the draft.

  @ Agree; proposea moving to the next section.
  [[ Changed in -07 ]]
  [[ RESOLVED - EDITORIAL ]]

==============================

* A010 Mar 03 Miguel Garcia <[email-masked]> (for Gen-ART)
  > - Section 3, anonymous ticket flag:
  >
  > The 4th paragraph in Section 3 misses a context with respect the 
anonymous
  > ticket flag. For example, I would have expected the text to answer these
  > questions: Is the anonymous ticket flag a new flag defined by this 
document
  > or defined elsewhere? What is the purpose of this flag?
  >
  > Perhaps the 4th paragraph should start by saying:
  >
  > "This document defines a new 'anonymous ticket flag' whose purpose is to
  > indicate that a request is being made anonymous" (or something like 
that).

  @ Propose following text to clarify:
  @ > This is a new ticket flag that is used to indicate a ticket is an
  @ > anonymous one.
  [[ I liked Miguel's text better, but whatever. --jhutz ]]
  [[ New text appears in -07 ]]
  [[ RESOLVED - EDITORIAL ]]

==============================

* A011 Mar 03 Miguel Garcia <[email-masked]> (for Gen-ART)
  > - Section 4, 1st paragraph, second line. Is the acronym "AS" correct for
  > "Authentication Exchange" ??? It looks it could be "AE" instead.
  >
  > Later, still in the 1st paragraph, but the 6th and 7th lines, the text
  > says: "... in an AS exchange"
  > So, if I replace "AS" with "Authenticate Exchange" then the sentence 
will
  > read: "... in an Authentication Exchange exchange", which obviously 
looks
  > bad.

  @ It should be "Authentication Service (AS) exchange".
  [[ Missing word "service" appears in -07 ]]
  [[ This could use word reordering, but it's not critical. --jhutz ]]
  [[ RESOLVED - EDITORIAL ]]

==============================

* A012 Mar 03 Miguel Garcia <[email-masked]> (for Gen-ART)
  > - Section 4, page 6, third paragraph on that page: There is normative 
text
  > in passive voice, and it wasn't immediately clear to me who is the 
subject
  > of the normative text. The text reads:
  >
  >     Identity-based authorization data SHOULD NOT be present in an
  >     anonymous ticket in that it typically reveals the client's identity.
  >
  > Presumably this "SHOULD NOT" strength should apply to the TGS, but I am 
not
  > sure. I would suggest to clarify and turn the sentence into active 
voice.
  > Perhaps the same is also applicable to other parts of the draft.

  @ Propose rewriting as active voice
  [[ Rewritten in -07 ]]
  [[ RESOLVED - EDITORIAL ]]

==============================

* A013 Mar 03 Miguel Garcia <[email-masked]> (for Gen-ART)
  > - Section 5, 1st paragraph on Page 8, reads:
  >
  >     " ... the initiator must NOT send "
  >
  > I guess this should be a normative "MUST NOT". If it isn't, then turn 
it to
  > "must not".

  @ Agreed; should be "MUST NOT"
  [[ Fixed in -07 ]]
  [[ RESOLVED - EDITORIAL ]]

==============================

* A014 Mar 03 Miguel Garcia <[email-masked]> (for Gen-ART)
  > - Section 8, IANA consideration. The text reads:
  >
  >     Section 3 defines the anonymous Kerberos name and the anonymous
  >     Kerberos realm based on [KRBNAM].  The IANA registry for [KRBNAM]
  >     need to be updated to add references to this document.
  >
  >
  > I think IANA will have trouble to parse the above text. I would suggest 
the
  > following:
  >
  >     This document defines a new 'anonymous' Kerberos name and a new
  > 'anonymous' Kerberos realm based on [KRBNAM]. IANA is requested to add
  > these two values to the Kerberos name and the Kerberos real registries 
that
  > are created in [KRBNAM].

  [[IANA reviewed this and had no problem with the existing text]]
  @ Looks ok, propose slight changes
  [[ Text changed in -07 ]]
  [[ RESOLVED - EDITORIAL ]]

==============================

* A015 Mar 20 Sam Hartman <[email-masked]>
  > The following requirement is impossible to implement:
  >
  > >   If a client requires anonymous communication then the client MUST
  > >   check to make sure that the ticket in the reply is actually 
anonymous
  > >      by checking the presence of the anonymous ticket flag.  This is
  >
  > As it turns out, a client cannot check ticket flags: it doesn't actually
  > know the key needed to decrypt the ticket.
  > Perhaps you mean that the client should check the KDC flags.

  @ The KDC duplicates the tickets flag in the EncKDCRepPart and the
  @ client can check that. I would propose the following changes to
  @ clarify this point.
  [[ Changed in -07 ]]
  [[ RESOLVED - MINOR SUBSTANTIVE ]]

==============================

* A016 Mar 20 Sam Hartman <[email-masked]>
  > if I call gss_display_name  on an anonymous principal in an
  > acceptor, what do I expect to get back?

  @ Would section 2.1.1 of RFC1964 be sufficient for this purpose?

  > Not really; as Ken points out, there is a mess surrounding GSS and
  > anonymous names.  See RFC2743 section 4.5.  Two anonymous names need
  > to compare not equal; special name type used; etc.
  > Martin said anonymous support in GSS is immature; I agree.
  > Also concerned about multiple ways to specify anonymous names for
  > the AS case; why do we need multiple ways?

  @ Offline discussion... propose to fix this by requiring the returned
  @ realm name MUST be the anonymous realm when anonymous PKINIT is used.
  @ This seems to resolve A016, pending WG consensus.
  [[ New requirement appears in -07 ]]

  [[ HUH?  This proposal addresses A018, but doesn't touch A016, which
  [[ appears to actually be the same as A023.
  [[ RESOLVED - dup of A023 ]]

==============================

* A017 Mar 20 Sam Hartman <[email-masked]>
  > if I provide the anonymous name to a KDC in an AS-REP with the
  > anonymous option set, but don't provide padata, should I expect
  > a preauth_required error from the KDC listing pkinit?

  @ Yes, I would like to propose the following new sentence into
  @ section 4 to make this clear.
  [[ New text added in -07 ]]
  [[ RESOLVED - MINOR SUBSTANTIVE ]]

==============================

* A019 Apr 04 Sam Hartman <[email-masked]>
  > How should anonymous realms interact with cross-realm policy?

  @ Would the following work?
  @ If the client realm in a ticket is the anonymous realm, absent other
  @ information any realm in the authentication path is allowed by the
  @ cross-realm policy check.

  <hartmans> OK
  [[ text present in -08 ]]
  [[ RESOLVED - substantive, discussed on list ]]

==============================

* A020 Apr 04 Sam Hartman <[email-masked]>
  > In the anonymous AS request, ...  which KDC do you contact for the
  > anonymous ticket?

  <hartmans> However I think that if you solve the authentication path
  <hartmans> issue you can leave it unspecified which KDC you go to.  So,
  <hartmans> my personal opinion is that if you close out the auth path
  <hartmans> issue the way you are planning to do, you can close out this
  <hartmans> issue as implementation defined.
  [[ RESOLVED ]]

==============================

* A021 Apr 04 Sam Hartman <[email-masked]>
  > you need to keep track somewhere in your credential cache what KDC
  > you talked to so you can select the right ticket.  [This] issue
  > should be mentioned in the draft but we probably don't want to give
  > requirements for solutions;

  <hartmans> This issue never existed in the first place as far as I can 
tell.
  [[ RESOLVED ]]

==============================

* A024 Apr 07 Ken Raeburn <[email-masked]>
  > Oh, yeah: One little nit in the anon-05 draft: In the first paragraph
  > of section 3, "WELLKNOWN:ANONYMOUS" has a line break after the colon.
  > I assume it was intended to not have any whitespace inserted there,
  > but from the .txt file as distributed it's slightly ambiguous.

  [[ Fixed in -08 ]]
  [[ RESOLVED ]]

==============================

* A025 Apr 30 Phillip Hallam-Baker <[email-masked]> (for secdir)
  > Abstract, without revealing the client's identity to whom?

  @ Without revealing the client's identity to the server or KDC.
  @ Propose to clarify abstract.
  [[ Changed in -07 ]]
  [[ RESOLVED - EDITORIAL ]]

==============================

* A026 Apr 30 Phillip Hallam-Baker <[email-masked]> (for secdir)
  > Section 6.
  > Clarification, 'a ticket that is returned is actually anonymous'.
  > A Kerberos server may not return a ticket at all and there are also
  > ticket granting tickets being used so use of the definite article
  > 'the ticket' is somewhat confusing.

  @ Context is that the client is required to examine the ticket in the
  @ reply.  There is only one reply ticket; I believe the text is clear.
  [[ Text seems clear to me in -07 ]]
  [[ RESOLVED - N/A ]]

==============================

* A027 Apr 30 Phillip Hallam-Baker <[email-masked]> (for secdir)
  > Clarification, although the draft mentions traffic analysis, this is a
  > somewhat broad term and the context seems to imply an interception
  > attack by a third party rather than call out the fact that a service
  > that is authenticated by this mechanism may be able to infer the
  > identity of the party by examining and linking quasi-static protocol
  > information such as the IP address from which a request is received.
  >
  > This is a pervasive problem in privacy protocols. Preventing a party
  > from obtaining irrefutable evidence that a particular party was engaged
  > in a particular transaction is rather easier than preventing a party
  > from being able to infer such involvement with a significant degree of
  > probability.

  @ This specific text in security considerations talks about the former
  @ (passive eavesdropping).
  [[ I believe Phillip's point was that the security considerations
  [[ SHOULD Call out the fact that a service that is authenticated by
  [[ this mechanism may be able to infer the identity of the party by
  [[ examining and linking quasi-static protocol information such as
  [[ the IP address from which a request is received.

  [[ Part of the above comment was added in -08 at the end of an
  [[ unrelated paragraph.  More cleanup is needed IMHO.

  [[ On second look, where the text was added seems fine.  There is
  [[ still some discussion on what exactly the text should be, but
  [[ this is quite close.

  [[ Further refinement has produced workable text.

  [[ PENDING reply from PHB by 26-Sep-2008 ]]
  [[ RESOLVED; no reply received ]]

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg