Subject: [OSPF] AUTH TYPE

From: Rajesh Shetty <[email-masked]>
Date: Fri, 21 Jan 2011 07:31:40 +0530

Hi Manav,

Auth Type we might need to add in AT(Authentication Trailer) Header for
extensibility.

Currently itself we can see the usage of Auth Type.

Auth Type = 0 = Cryptographic authentication

Auth Type = 1 (May be) = Cryptographic authentication with Session ID/Nonce
support (security extension for ospfv3 when using manual key management)

So its better to replace Reserved filed with Auth Type.

Thanks

Rajesh.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 25 Jan 2011 04:37:37 +0530

Hi Rajesh,

I agree that such a distinction is indeed required. However, cant the KeyID be used for such purposes? How about also associating the authentication type with the Key ID. Thus one knows that if the incoming packet is coming with KeyID X then its normal cryptographic authentication, and if its coming with Y, then its the crypto session with Session ID and Nonce. This would also dictate how this packet should be further parsed.

I am btw also amenable to the idea of breaking the 16 bit reserved field into an 8 bit reserved field and an 8 bit AuType field. However, just want to make sure that we absolutely need this before doing it.

Would also like to hear what others in WG think about this.

Cheers, Manav

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rajesh Shetty
Sent: Friday, January 21, 2011 7.32 AM
To: [email-masked]
Subject: [OSPF] AUTH TYPE

Hi Manav,

Auth Type we might need to add in AT(Authentication Trailer) Header for extensibility.
Currently itself we can see the usage of Auth Type.

Auth Type = 0 = Cryptographic authentication
Auth Type = 1 (May be) = Cryptographic authentication with Session ID/Nonce support (security extension for ospfv3 when using manual key management)

Thanks
Rajesh.

---

From: Michael Barnes <[email-masked]>
Date: Tue, 25 Jan 2011 20:46:33 -0800

Hi Manav,

I think it's fine to use the Key ID to also indicate the authentication 
type. However the name Key ID seems inappropriate since it now indicates 
more than just the key. I suggest to use a different name for this 
field, such as SA ID.

Regards,
Michael

On 01/24/2011 03:07 PM, Bhatia, Manav (Manav) wrote:
>
> Hi Rajesh,
> I agree that such a distinction is indeed required. However, cant the
> KeyID be used for such purposes? How about also associating the
> authentication type with the Key ID. Thus one knows that if the incoming
> packet is coming with KeyID X then its normal cryptographic
> authentication, and if its coming with Y, then its the crypto session
> with Session ID and Nonce. This would also dictate how this packet
> should be further parsed.
> I am btw also amenable to the idea of breaking the 16 bit reserved field
> into an 8 bit reserved field and an 8 bit AuType field. However, just
> want to make sure that we absolutely need this before doing it.
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Rajesh Shetty
>     *Sent:* Friday, January 21, 2011 7.32 AM
>     *To:* [email-masked]
>     *Subject:* [OSPF] AUTH TYPE
>
>     Hi Manav,
>
>     Auth Type = 1 (May be) = Cryptographic authentication with Session
>     ID/Nonce support (security extension for ospfv3 when using manual
>     key management)
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 26 Jan 2011 10:33:48 +0530

Hi Michael,

Clipped from RFC 5709:

"Key Identifier (KeyID)
 This is an 8-bit unsigned value used to uniquely identify an
 OSPFv2 SA and is configured either by the router administrator
 (or, in the future, possibly by some key management protocol
 specified by the IETF).  The receiver uses this to locate the
 appropriate OSPFv2 SA to use.  The sender puts this KeyID value in
 the OSPF packet based on the active OSPF configuration."

Do you still think that this needs to be renamed?

Given that the authentication mechanism to be used will be a part of the Security Association. Also given that a Key ID uniquely identifies an SA. Shouldn't we just continue using KeyID?

Cheers, Manav 

> -----Original Message-----
> From: Michael Barnes [mailto:[email-masked]] 
> Sent: Wednesday, January 26, 2011 10.17 AM
> To: Bhatia, Manav (Manav); OSPF List
> Subject: Re: [OSPF] AUTH TYPE
> 
> Hi Manav,
> 
> >     Auth Type we might need to add in AT(Authentication 
> Trailer) Header
> >     for extensibility.
> >

---

From: Michael Barnes <[email-masked]>
Date: Tue, 25 Jan 2011 21:39:33 -0800

Hi Manav,

Yes. The name Key ID in v2 is archaic. When it was defined there was no 
choice of algorithm. It's no longer accurate but we continue to use it 
for continuity. I think we can break the tradition and use a more 
accurate name for v3.

Regards,
Michael

---

From: RajeshShettyM 70520 <[email-masked]>
Date: Wed, 26 Jan 2011 15:09:55 +0500

Dear Manav,

i think idea of breaking 16 bit reserved field into an 8 bit reserved field and an 8 bit AuType field is better.

About associating auth type with Key ID, this option seems to be risky in case of misconfiguration (or transient configuration condition).if sender sends with Key ID X (Normal Cryptographic authentication) and in receiver KEY ID X is configured for [crypto session with Session ID and Nonce],then the packet processing might result into exception.

Thanks
Rajesh

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it!
 *****************************************************************************************

----- Original Message -----
From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tuesday, January 25, 2011 4:37 am
Subject: RE: [OSPF] AUTH TYPE
To: Rajesh Shetty <[email-masked]>, "[email-masked]" <[email-masked]>

> Hi Rajesh,
> 
> I agree that such a distinction is indeed required. However, cant 
> the KeyID be used for such purposes? How about also associating the 
> authentication type with the Key ID. Thus one knows that if the 
> incoming packet is coming with KeyID X then its normal 
> cryptographic authentication, and if its coming with Y, then its 
> the crypto session with Session ID and Nonce. This would also 
> dictate how this packet should be further parsed.
> 
> I am btw also amenable to the idea of breaking the 16 bit reserved 
> field into an 8 bit reserved field and an 8 bit AuType field. 
> However, just want to make sure that we absolutely need this before 
> doing it.
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 26 Jan 2011 16:04:58 +0530

Hi Rajesh,

I don't think so. In this case it should just fail the authentication, or the basic parsing checks should fail and the packet should be rejected. I see no reason why this would lead to an exception.

Cheers, Manav

> From: RajeshShettyM 70520 [mailto:[email-masked]] 
> Sent: Wednesday, January 26, 2011 3.40 PM
> To: Bhatia, Manav (Manav)
> Cc: [email-masked]
> Subject: Re: RE: [OSPF] AUTH TYPE
> 
> Dear Manav,
> 
> i think idea of breaking 16 bit reserved field into an 8 bit 
> reserved field and an 8 bit AuType field is better.
> 
> About associating auth type with Key ID, this option seems to 
> be risky in case of misconfiguration (or transient 
> configuration condition).if sender sends with Key ID X 
> (Normal Cryptographic authentication) and in receiver KEY ID 
> X is configured for [crypto session with Session ID and 
> Nonce],then the packet processing might result into exception.
> 
> 
> Thanks
> Rajesh
> 
> 
> 
> 
> 
>  This email and its attachments contain confidential 
> information from HUAWEI, which is intended only for the 
> person or entity whose address is listed above. Any use of 
> the information contained here in any way (including, but not 
> limited to, total or partial disclosure, reproduction, or 
> dissemination) by persons other than the intended 
> recipient(s) is prohibited. If you receive this email in 
> error, please notify the sender by phone or email immediately 
> and delete it!
>

---

From: RajeshShettyM 70520 <[email-masked]>
Date: Wed, 26 Jan 2011 16:32:32 +0500

Dear Manav,

PreCondition:
sender sends with Key ID X (Normal Cryptographic authentication) and in receiver KEY ID X is configured for [crypto session with Session ID and Nonce].

Receiver side Packet Processing:
On the Receiver Side i am not Fully convinced with idea of Mistreating authentication data as [Session ID and Nonce value] and probably dropping the packet.

for some reason if we don't drop the packet then receiver would have already skipped 8 bytes of authentication Data interpreting that it is SESSION ID (4 bytes)and Nonce Value(4 bytes). From This offset if receiver reads authentication data as mentioned in Authentication Data Length field in AT Header then certain parsing problems can occur.

Please check, if i am missing something let me Know.

Thanks
Rajesh

----- Original Message -----
From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wednesday, January 26, 2011 4:05 pm
Subject: RE: RE: [OSPF] AUTH TYPE
To: RajeshShettyM 70520 <[email-masked]>
Cc: "[email-masked]" <[email-masked]>

> Hi Rajesh,
> 
> I don't think so. In this case it should just fail the 
> authentication, or the basic parsing checks should fail and the 
> packet should be rejected. I see no reason why this would lead to 
> an exception.
> 
> Cheers, Manav
> 
> > > Auth Type we might need to add in AT(Authentication Trailer) 
> Header 
> > > for extensibility.